From jiangsheng@huawei.com Mon Jul 1 00:45: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 E83FA21F8F15 for ; Mon, 1 Jul 2013 00:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQhMXGwfJo6y for ; Mon, 1 Jul 2013 00:45:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F410421F8EC3 for ; Mon, 1 Jul 2013 00:45:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASZ89212; Mon, 01 Jul 2013 07:45:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 08:44:10 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 08:45:05 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 1 Jul 2013 15:44:59 +0800 From: Sheng Jiang To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-jiang-dhc-sedhcpv6-00.txt Thread-Index: AQHOdKaNiCaJoAj6R0e4hxYZTUg3I5lPVibw Date: Mon, 1 Jul 2013 07:44:58 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACA7B8D@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dhcwg] FW: New Version Notification for draft-jiang-dhc-sedhcpv6-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, 01 Jul 2013 07:45:25 -0000 SGksIERIQywNCg0KQWx0aG91Z2ggdGhpcyBpcyBhIG5ldyBpbmRpdmlkdWFsIGRyYWZ0LiBJdCBp cyBhY3R1YWxseSB0aGUgcmVwbGFjZW1lbnQgb2YgZHJhZnQtaWV0Zi1kaGMtc2VjdXJlLWRoY3B2 Niwgd2hpY2ggcmVhY2hlZCBJRVNHIGFuZCBkZWFkIGJlY2F1c2Ugb2YgY29uc2lkZXJhdGlvbiBy ZWdhcmRpbmcgdG8gQ0dBLiBJdCB3YXMgcG9pbnRlZCBvdXQgdGhhdCB0aGUgdXNlIG9mIENHQXMg aW4gdGhpcyBzaXR1YXRpb24gKDEpIGlzbid0IHJlYWxseSBob3cgdGhleSB3ZXJlIGludGVuZGVk IHRvIGJlIHVzZWQgYW5kICgyKSBwcm9iYWJseSBkb2Vzbid0IGFkZCBhbnkgdmFsdWUgb3ZlciBh IHJlZ3VsYXIgcHVibGljIGtleSBzaWduYXR1cmUuIEEgc3VnZ2VzdGlvbiBmcm9tIElFU0cgaXMg dG8gbWFrZSBhbm90aGVyIHB1YmxpYyBrZXkgYmFzZWQgc2VjdXJpdHkgc29sdXRpb24sIHdoaWxl IHRoZXJlIHdhcyBkZXNpcmVzIHRoYXQgREhDUHY2IG5lZWQgYW5vdGhlciBzZWN1cml0eSBtZWNo YW5pc20gYmV5b25kIHN5bW1ldHJpYyBrZXkgcGFpci4NCg0KQWNjb3JkaW5nIHRvIElFU0cgcmV2 aWV3IGFuZCBhZ3JlZW1lbnQgd2l0aCBBRCwgd2Ugd3JvdGUgdGhlIG5ldyBkcmFmdC4gSW4gaXQs IHRoZSBhdXRob3JzIGRyb3BwZWQgQ0dBIHJlbGV2YW50IG1lY2hhbmlzbSwgbWFraW5nIGl0IGdl bmVyYWwgcHVibGljIGtleSBiYXNlZC4gQ29tcGFyaW5nIHRvIG9sZCB2ZXJzaW9uLCB3ZSBhbHNv IGFkZGVkIFBLSSBhcyBhbiBhbHRlcm5hdGl2ZSBvZiBwcmUtY29uZmlnLCB3aGlsZSBrZWVwaW5n ICJhIGxlYXAgb2YgZmFpdGgiIG1vZGVsIHBvc3NpYmxlLiBXZSBhbHNvIGNvbXBsZXRlIHRpbWVz dGFtcCBjaGVjayBtZWNoYW5pc20uDQoNCkJhc2VkIG9uIHRoZSBwdWJsaWMga2V5LCB0aGlzIG1l Y2hhbmlzbSBwcm92aWRlcyBhdXRoZW50aWNhdGlvbiBvZiBESENQdjYgc2VuZGVyLCBwcm90ZWN0 IHRoZSBpbnRlZ3JpdHkgb2YgREhDUHY2IG1lc3NhZ2VzIGFuZCBhbnRpIHJlcGxheS4NCg0KQmVz dCByZWdhcmRzLA0KDQpTaGVuZyArIFNlYW4NCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+U2VudDogU2F0dXJkYXksIEp1bmUgMjksIDIwMTMgNDo1NiBQTQ0KPlRv OiBTaGVuZyBKaWFuZzsgU2VhbiBTaGVuDQo+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDAudHh0DQo+DQo+DQo+QSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWppYW5nLWRoYy1zZWRoY3B2Ni0wMC50eHQNCj5oYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ SUVURiByZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1lOgkgZHJhZnQtamlhbmctZGhjLXNlZGhjcHY2 DQo+UmV2aXNpb246CSAwMA0KPlRpdGxlOgkJIFNlY3VyZSBESENQdjYgd2l0aCBQdWJsaWMgS2V5 DQo+Q3JlYXRpb24gZGF0ZToJIDIwMTMtMDYtMjkNCj5Hcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj5OdW1iZXIgb2YgcGFnZXM6IDE1DQo+VVJMOg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5nLWRoYy1zZWRoY3B2Ni0wMC50eHQNCj5TdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctZGhj LXNlZGhjcHY2DQo+SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDANCj4NCj4NCj5BYnN0cmFjdDoNCj4gICBUaGUgRHlu YW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQdjYgKERIQ1B2NikgZW5hYmxl cw0KPiAgIERIQ1B2NiBzZXJ2ZXJzIHRvIHBhc3MgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiBJ dCBvZmZlcnMNCj4gICBjb25maWd1cmF0aW9uIGZsZXhpYmlsaXR5LiBJZiBub3Qgc2VjdXJlZCwg REhDUHY2IGlzIHZ1bG5lcmFibGUgdG8NCj4gICB2YXJpb3VzIGF0dGFja3MsIHBhcnRpY3VsYXJs eSBzcG9vZmluZyBhdHRhY2tzLiBUaGlzIGRvY3VtZW50DQo+ICAgYW5hbHl6ZXMgdGhlIHNlY3Vy aXR5IGlzc3VlcyBvZiBESENQdjYgYW5kIHNwZWNpZmllcyBhIFNlY3VyZSBESENQdjYNCj4gICBt ZWNoYW5pc20uIFRoaXMgbWVjaGFuaXNtIGlzIGJhc2VkIG9uIHB1YmxpYy9wcml2YXRlIGtleSBw YWlycy4gVGhlDQo+ICAgYXV0aG9yaXR5IG9mIHRoZSBzZW5kZXIgbWF5IGRlcGVuZCBvbiBlaXRo ZXIgcHJlLWNvbmZpZ3VyYXRpb24NCj4gICBtZWNoYW5pc20gb3IgUHVibGljIEtleSBJbmZyYXN0 cnVjdHVyZS4NCj4NCj4NCj4NCj4NCj4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From praspati@cisco.com Mon Jul 1 06:31: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 F3A9011E811F for ; Mon, 1 Jul 2013 06:31:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2bpsav2m7Jl for ; Mon, 1 Jul 2013 06:31:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 37FCC11E80D7 for ; Mon, 1 Jul 2013 06:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5299; q=dns/txt; s=iport; t=1372685458; x=1373895058; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iAUUYWSByJ20jt3F9mziGCdt84If7gZ89nbFGe3pG1k=; b=i1YfbWA84TFrGXww7SJiqlIV7lZm3U8Wl8eL3rYwhKhzqDBD6teqLyvs i6/UoEsSueMh26CcmzGX75t2SPiKD78HHm8gmR9cnTi7jotFEThrXFr9K K5VC0dnDi9e4NH0TjvREn69/vkERuOYazKJEfJk66ASZ8EOWS2v1cQXlN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHOC0VGtJXG8/2dsb2JhbABagwkyQwa/GH0WdIIjAQEBBAEBATc0CQIMBgEIEQQBAQsUCS4LFAgBCAIEAQ0FCAGIBgcFu1GPLTEHBoJ+YwOYcZAcgViBOYIo X-IronPort-AV: E=Sophos;i="4.87,974,1363132800"; d="scan'208";a="229508127" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 01 Jul 2013 13:30:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r61DUtGa011368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Jul 2013 13:30:55 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 08:30:55 -0500 From: "Prashanth Patil (praspati)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaAgCCgIMCABSSwgA== Date: Mon, 1 Jul 2013 13:30:54 +0000 Message-ID: In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185C9F90@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [173.39.67.75] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 01 Jul 2013 13:31:08 -0000 Hi Bernie, On 28/06/13 11:10 PM, "Bernie Volz (volz)" wrote: >Isn't this also only half the problem? And doesn't it cause more work for >the relay? > >What I mean is shouldn't there also be an option for the relay to >communicate this for "normal" client traffic? I.e., all Relay-Forws. >There might be more values (such as unknown) to be considered -- though I >guess not including the option could imply that. Yes, this can be extended to relay forwards as well. In some cases, the relay could already be aware of network characteristics which can be indicated during a relay forward. The focus of the draft was to propose a means to do this dynamically whenever the relay learns network characteristics - especially in the DNS case where the relay determines transitions such as IPv6-only to dual-stack, dual-stack to IPv6-only and dual-stack to IPv4-only. > >Doesn't this also imply that the relay would have to monitor what the >server provided the client to know if it was wrong (and hence trigger a >reconfigure). I guess the relay could just do this when things (regarding >the client's provisioning) changed. > >But what then happens if the client sends requests to the server at a >later time? There's no signaling to the server from the relay as to what >to send then? If the server sends the wrong information, how would the >relay know without monitoring what the server actually delivers to the >client (as there may not be a change in the client's connective). > >While you could require the server to remember this from a >Reconfigure-Request, that seems rather onerous and has issues if this >state is lost or becomes stale (i.e., server misses updates from relay). > >Also, this mechanism currently requires the clients to support >Reconfigure. Otherwise, the relay's request doesn't cause any change at >the client. > >And, this again is where having this be a normal part of the Relay-Forw >would be useful -- at least the server then has the ability to update the >client at the next communication. Right, currently the draft states that the relay only does this when things change and doesn't have to monitor server responses. As you suggest it would be useful to have this as part of subsequent Relay-Forw and not have the server remember these. > >Note also that server policy to use perhaps shorter Information-Refresh >or T1 times when this information isn't available or the relay reports it >is 'unknown' could be used to 'correct' the information in the client >more quickly once it is determined? > >It would also be nice if this was expanded to handle more than DNS -- >though exactly what else would use that information isn't completely >clear. Sure. The idea is to make this more generic and handle more than just DNS, we'll update the draft. -Prashanth > >Anyway, looks like this work will be discussed in the Sunset4/DHC WG >joint session at Berlin (as well as at the DHC wg session). > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >Prashanth Patil (praspati) >Sent: Friday, June 07, 2013 8:45 AM >To: dhcwg@ietf.org >Cc: Tirumaleswar Reddy (tireddy) >Subject: [dhcwg] FW: New Version Notification for >draft-wing-dhc-dns-reconfigure-01.txt > >Hi all, >This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 Relay >Agent can dynamically influence priority of DNS servers provided to a >host, so that a host can use an optimal DNS server for resolution. > > >Regards, >Prashanth > >On 07/06/13 6:05 PM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt >>has been successfully submitted by Dan Wing and posted to the >>IETF repository. >> >>Filename: draft-wing-dhc-dns-reconfigure >>Revision: 01 >>Title: DHCPv6 Dynamic DNS Reconfiguration >>Creation date: 2013-06-07 >>Group: Individual Submission >>Number of pages: 8 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure-01.txt >>Status: =20 >>http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure >>Htmlized: =20 >>http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-dhc-dns-reconfigure-01 >> >>Abstract: >> Some networks are expected to support IPv4-only, dual-stack, and >> IPV6-only hosts at the same time. This makes prioritizing the DNS >> servers for hosts tricky due to a heterogeneous mix of protocol >> stacks causing optimal behavior to occur only when the host stack re- >> initializes. The networks infrastructure is usually well equipped to >> be aware of single/dual-stack nature of hosts. This specification >> extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence >> the priority of DNS servers provided to the host, so that the host >> can use an optimal DNS server for resolution. >> >> =20 >> =20 >> >> >>The IETF Secretariat >> > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From praspati@cisco.com Mon Jul 1 06:32: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 DA59411E80E8 for ; Mon, 1 Jul 2013 06:32:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEHcX5GoRhSH for ; Mon, 1 Jul 2013 06:32:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F38E311E811B for ; Mon, 1 Jul 2013 06:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1064; q=dns/txt; s=iport; t=1372685542; x=1373895142; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bq+jZh9I4mzZs8ff7ZxaIPZehIOlfp4TtKVgTtgQowg=; b=lD686eiVhg2E1Z7Xub+UZGktIEtzBRfijzQoDtjGotrePK3krerIyC19 7+awnywCMPe3nnWti8ufD0xg5HwFue+bPWNgKtMcnVCZiQZeEGWGpiik4 EbPEkO/dD5O6uiui2sVnxdwC+EOmmpLsrhzdHFvfkmiSJf7JoFH6+7cTQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPaD0VGtJXG8/2dsb2JhbABagwl7vxh8FnSCIwEBAQQ6PQISAQgYChRCJQIEDgUIiAe7Xo8tMQeDBGMDk3aVF4MRgig X-IronPort-AV: E=Sophos;i="4.87,974,1363132800"; d="scan'208";a="229232574" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jul 2013 13:32:21 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r61DWLe4013886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 13:32:21 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 08:32:21 -0500 From: "Prashanth Patil (praspati)" To: Ted Lemon Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaAgCD5gwCABMu2gA== Date: Mon, 1 Jul 2013 13:32:20 +0000 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751F0BE8@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [173.39.67.75] Content-Type: text/plain; charset="us-ascii" Content-ID: <39CF619529081B438A34F62C3E94C393@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 01 Jul 2013 13:32:28 -0000 Hi Ted, On 28/06/13 11:18 PM, "Ted Lemon" wrote: >On Jun 7, 2013, at 8:44 AM, Prashanth Patil (praspati) > wrote: >> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6 >>Relay >> Agent can dynamically influence priority of DNS servers provided to a >> host, so that a host can use an optimal DNS server for resolution. > >Why don't you just configure the DHCP server to return DNS servers in a >different order for different links? Links are identified by relay >agent, so this gets you the precise behavior you want, but with a >centralized configuration file rather than with per-relay configuration. Yes, this was one of the suggestions made earlier. Notification from relay then becomes generic and not specific to DNS. The server decides whatever actions need to be done, such as reconfiguring DNS server lists. -Prashanth > >If you really want the relay to be the source of knowledge about DNS, why >not return DNS servers via a relay-supplied options option? > From tomasz.mrugalski@gmail.com Mon Jul 1 08:07:29 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 546B411E8160 for ; Mon, 1 Jul 2013 08:07:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YigA+edRrsMG for ; Mon, 1 Jul 2013 08:07:28 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BC18511E814E for ; Mon, 1 Jul 2013 08:07:23 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it16so1794174bkc.27 for ; Mon, 01 Jul 2013 08:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :x-forwarded-message-id:content-type:content-transfer-encoding; bh=KJ+GhS6lCvDuxwAR2zn5wNuCgDbHF3Z81XC95SRHFqs=; b=oiGUXV3zh56zVSsV/kuyZdYh2iqqhrdzjxgnL6BcINJ3ethyMg7Om1tCf3tJZmRl0t WuHBW12juIAYJykzeG+xIDz4hTgYlM4fU11iuhf6eMy2IHNvChh081wHTezqeg1JdnII mL8CGqm3UkDcnx1fEPPA1ps8e2CZ1t0NT4zfx9o5jYHTqSK7T8MQ3AjzH4zd+KDfS7yV 8ZMPsRf3b07NsCodhjL+cp8jY54lNlIIantAJIPKVwy+3/gt7R0e1m1HdajiFIbCz2la +nmXZl6avM8PZ0XXHnIfCGQE3YLUD2gk9iHC5qux+LFEhYN17F+tIiin6sfod3c7vIJh l7Mw== X-Received: by 10.204.62.137 with SMTP id x9mr3249255bkh.90.1372691242769; Mon, 01 Jul 2013 08:07:22 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id l11sm8863173bkk.13.2013.07.01.08.07.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 08:07:21 -0700 (PDT) Message-ID: <51D19B1F.50502@gmail.com> Date: Mon, 01 Jul 2013 17:07:11 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130701170711149 X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: dhcwg Subject: [dhcwg] Fwd: AD Review of draft-ietf-dhc-dhcpv6-failover-requirements 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, 01 Jul 2013 15:07:29 -0000 FYI -------- Original Message -------- Subject: AD Review of draft-ietf-dhc-dhcpv6-failover-requirements Resent-To: kkinnear@cisco.com, tomasz.mrugalski@gmail.com Date: Sun, 30 Jun 2013 17:51:57 -0400 From: Ted Lemon To: draft-ietf-dhc-dhcpv6-failover-requirements@tools.ietf.org I'm doing the pre-submission review for this document now (sorry I took so long to get started) and have a couple of comments that should be addressed before I submit this to the IESG: There's no such thing as a zone name. A zone is just a point in the DNS tree where there's an SOA record. Suggested fix: OLD: FQDN - a fully qualified domain name. A fully qualified domain name generally is a host name with at least one zone name. For example "dhcp.example.org" is a fully qualified domain name. NEW: FQDN - a fully qualified domain name. A fully qualified domain name generally is a host name with at least one domain label under the top-level domain. For example "dhcp.example.org" is a fully qualified domain name. Prior to section 8, this document was pretty agnostic about how the problem would be solved, but section 8 makes the transition to specifying what looks like requirements for a failover protocol much like the DHCPv4 failover protocol. It would help to add some text justifying this transition, since I don't think you really did prior to section 8. The basic point you need to get across is that a two-way failover protocol is much simpler than a multi-way failover protocol, and a multi-way failover protocol doesn't add a whole lot of value. Also, you can't use MUST, MUST NOT, etc in a requirements document, because you aren't specifying protocol behavior. You never reference RFC2119, so you don't have to follow or avoid its conventions—it makes sense to just use the english words without uppercasing them. What's the point of section 9.1? This is a rather long section about another protocol, almost as if you'd done a DHCPv4 failover requirements document. >From Section 10: The design of a security protection MUST take into consideration the fact that the protocol MUST operate despite network failures. In particular, relying on any external infrastructure (e.g. any form of Certificate Authority) is discouraged (or at least must be optional). What's the motivation for this text? TLS certs work without access to the certifying server, although you don't get revocation. This is a pretty big requirement to place on the protocol, because it excludes the use of TLS. It's hard to see the value in it. Anyway, as I say, sorry for taking so long to do this review. The above comments are significant enough that I'd like to see them addressed before we go to IESG review. If you think I'm mistaken about any of these observations, an appropriate response would be to explain why—I don't claim to be omniscient. From volz@cisco.com Mon Jul 1 08:48: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 DA3CA11E8147 for ; Mon, 1 Jul 2013 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ0ODl6F4MiZ for ; Mon, 1 Jul 2013 08:48:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEE11E823B for ; Mon, 1 Jul 2013 08:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10142; q=dns/txt; s=iport; t=1372693686; x=1373903286; h=from:to:cc:subject:date:message-id:mime-version; bh=gzS0KMEgw4hkE7iYrssyx9NfHBq82QjUbwvFkHsXtls=; b=Xu1FucxqgizO3xDycpSxOvSRG6C5o5fCy6PKnuOJXDgYUj03iNnuJLi5 9BI4LQL4eT98+9z2OHAGckCyr3ssPK7btkn/CBtCMoCCaTRlgtTFgIJVK rnU1b3ze4286Go238P7WkfycnlPZi61l7rgR99cYOUxc/wKDiFwqSzqyC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAIuj0VGtJXG+/2dsb2JhbABagkVEMkmtKYk2iDp8FnSCJQEELUELEgEqViYBBA4NiAcMvAePLTGDC2MDmHGKeoUigxGCKA X-IronPort-AV: E=Sophos;i="4.87,974,1363132800"; d="scan'208,217";a="226518120" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 01 Jul 2013 15:48:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r61Fm3jC021790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 15:48:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 10:48:03 -0500 From: "Bernie Volz (volz)" To: "Dhc Chairs (dhc-chairs@tools.ietf.org)" Thread-Topic: Updated WG Milestones - Need Input from Authors! Thread-Index: Ac52cdTF4rU87c6LSB+uUSH5Jj4FJw== Date: Mon, 1 Jul 2013 15:48:02 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CD223@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.86.240.243] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185CD223xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: [dhcwg] Updated WG Milestones - Need Input from Authors! 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, 01 Jul 2013 15:48:11 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185CD223xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: We need to update the WG milestones as they are rather out of date (last en= try is for Jul 2008). While Tomek and I could put milestones in which you c= ould bash, we'd prefer to get your input into the process. Therefore, for any WG document and explicitly mentioned items in the re-cha= rter (see http://datatracker.ietf.org/doc/charter-ietf-dhc/), we need some = milestones. Thus, we are asking any document authors to provide us with app= ropriate milestones. To view what typically ends up in the milestones, plea= se review the charters for working groups at http://datatracker.ietf.org/wg= (WGLC, IESG submission are typically used). Please respond (and please only to the dhc-chairs - use REPLY, not REPLY-AL= L) by July 12th as we'd like to distribute the draft milestones the week of= July 15th and discuss in Berlin (as well as on the mailing list). Here's a start at this for some of the items Tomek and I are authors for an= d that are key for the WG to work on: Jul 2013 Submit SOLMAXRT to IESG Jul 2013 Submit option guidelines to IESG Jul 2013 Submit failover requirements to IESG Aug 2013 WG last call on failover design Oct 2013 Submit issues with stateful options to IESG Oct 2013 Submit failover design to IESG Nov 2013 Assign editor and core team for 3315-bis work Nov 2014 WG last call on 3315-bis Apr 2015 Submit 3315-bis to IESG Thanks in advance and sorry for the wide distribution. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E185CD223xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

We need to update the WG milestones as they are rath= er out of date (last entry is for Jul 2008). While Tomek and I could put mi= lestones in which you could bash, we’d prefer to get your input into = the process.

 

Therefore, for any WG document and explicitly mentio= ned items in the re-charter (see http://datatr= acker.ietf.org/doc/charter-ietf-dhc/), we need some milestones. Thus, w= e are asking any document authors to provide us with appropriate milestones= . To view what typically ends up in the milestones, please review the charters for working groups at http://datatracker.ietf.org/wg (WGLC, IESG submission are typically use= d).

 

Please respond (and please only to the dhc-chairs &#= 8211; use REPLY, not REPLY-ALL) by July 12th as we’d like to distrib= ute the draft milestones the week of July 15th and discuss in Be= rlin (as well as on the mailing list).

 

Here’s a start at this for some of the items T= omek and I are authors for and that are key for the WG to work on:

 

Jul 2013  Submit SOLMAXRT= to IESG

Jul 2013  Submit option g= uidelines to IESG

Jul 2013  Submit failover= requirements to IESG

Aug 2013  WG last call on= failover design

Oct 2013  Submit issues w= ith stateful options to IESG

Oct 2013  Submit failover= design to IESG

Nov 2013  Assign editor a= nd core team for 3315-bis work

Nov 2014  WG last call on= 3315-bis

Apr 2015  Submit 3315-bis= to IESG

 

Thanks in advance and sorry for the wide distributio= n.

 

-     &= nbsp;    Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E185CD223xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Mon Jul 1 11:58: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 0814B11E823F for ; Mon, 1 Jul 2013 11:58:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wDUi1znq1Sf for ; Mon, 1 Jul 2013 11:58:04 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8701411E823A for ; Mon, 1 Jul 2013 11:58:04 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUdHRPCY47w1sDY0VMC6xpr+UsarhmuJ5@postini.com; Mon, 01 Jul 2013 11:58:04 PDT 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 B07B71B821F for ; Mon, 1 Jul 2013 11:58:03 -0700 (PDT) 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 7FC9319005D; Mon, 1 Jul 2013 11:58:03 -0700 (PDT) (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, 1 Jul 2013 11:58:03 -0700 From: Ted Lemon To: "Prashanth Patil (praspati)" Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOdCenS2HB7oYtEky7nP+0jJgy+ZlQS9sAgABa/4A= Date: Mon, 1 Jul 2013 18:58:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F61CD@mbx-01.win.nominum.com> References: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 01 Jul 2013 18:58:23 -0000 (ad hat off) On Jul 1, 2013, at 9:32 AM, Prashanth Patil (praspati) = wrote: > Yes, this was one of the suggestions made earlier. Notification from rela= y > then becomes generic and not specific to DNS. The server decides whatever > actions need to be done, such as reconfiguring DNS server lists. I'm sorry, but you did not answer my question. The question was this: >> Why don't you just configure the DHCP server to return DNS servers in a >> different order for different links? Links are identified by relay >> agent, so this gets you the precise behavior you want, but with a >> centralized configuration file rather than with per-relay configuration. That is, I am not suggesting this as an alternative. I am asking you why = you don't consider this to be a better alternative. The reason I ask is that what you are proposing is extremely harmful. You= are requiring new special protocol extension with new special-case code to= be added to the DHCP server to handle this use case, and you are requiring= that relay agents throughout the network be individually configured to spe= cify behavior on the DHCP server, which is a maintenance nightmare. So if you want to do something this harmful, you should have a good explana= tion for why it's better than the alternative. From tomasz.mrugalski@gmail.com Mon Jul 1 13:55:30 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 60F3711E8143 for ; Mon, 1 Jul 2013 13:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARmhIiH5z9Uj for ; Mon, 1 Jul 2013 13:55:29 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4954E11E825F for ; Mon, 1 Jul 2013 13:55:28 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so1924245bkc.4 for ; Mon, 01 Jul 2013 13:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:x-forwarded-message-id:content-type :content-transfer-encoding; bh=Myr6havTzam7C1bYTkSmbKOYiCEPXVPEbGbrMllQbss=; b=ziv3cab1gQ4Iwm42SyZ4jgeBx8ndGNVFlx3KSXpto2bbp5976o+JrhsSUpioiJwF6d Jnx1PO1R/85/89MUClFQ+HPv0PMYvKK0HCGBN8lxlzqvPQk7RufN6EXEwWSM+0R5lWnq N53rp8pkzUhwsuKfQKfNh79GGxghB4F+f6HwkXqrI7vFxWeGAr4ULcf5wiecf+x2KT5+ ZlG2DHxmrVJ3RDtlgDFgfLNwVFZdS3nk4BNNvTAVW70WP7cguLBHDVrGYJTjYddxshBZ sk8OXO9i3EvfSZJpNX/ir3OyUFePr46wce9UwYVUpHUufUUBIfR39540X602t/QEyDDG +Yuw== X-Received: by 10.204.228.207 with SMTP id jf15mr3494177bkb.16.1372712128007; Mon, 01 Jul 2013 13:55:28 -0700 (PDT) Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id de17sm9685191bkb.5.2013.07.01.13.55.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 13:55:26 -0700 (PDT) Message-ID: <51D1ECBC.2070103@gmail.com> Date: Mon, 01 Jul 2013 22:55:24 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: DHC WG References: <51D1EB5A.7020803@klub.com.pl> In-Reply-To: <51D1EB5A.7020803@klub.com.pl> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <51D1EB5A.7020803@klub.com.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Comments on 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: Mon, 01 Jul 2013 20:55:30 -0000 On 13.06.2013 20:36, Andre Kostur wrote: > Some general clarification questions (inline): I'm very sorry it took me so long to get back to this thread. > The text mentions a case of 2 servers, with the first one going offline > and the second server taking over all clients. The text says that once > the first server recovers and the second server ignores RENEWs, > eventually the first server will be able to respond clients that start > REBINDing. This will cause the clients to constantly go through > REQUEST->failed RENEW attempts->REBIND cycles, even when both servers > are fine. Nothing really gained, but you just introduced REBINDs to > perfectly healthy network (with the extra processing needed for REBINDs > and possible warnings all around, as REBIND is usually a sign of > troubles). > This shouldn't result in a constant cycle, only one cycle (where > "primary client" == a client which should be answered by the primary > server in a LB+Failover pair, and "secondary client" == a client which > should be answered by the secondary server in a LB+Failover pair): > 1) All servers are healthy > 2) Primary server fails > 3) A set of clients come online. (mix of primary and secondary > clients). The Secondary clients are perfectly happy as the secondary > server is still online. The primary clients get serviced by the > secondary server as well, as the secondary server knows that the primary > is offline. How can a server know that its partner is down? Is there some heuristic to detect that? One thing comes to mind is to observe increasing elapsed time values, but you explicitly say that Delayed Service Parameter SHOULD NOT be used. Also, keep in mind that the load balancing with its HBA mechanism allows (at least in theory) more than two servers to cooperate, so the answer may be more complex than just either "everyone's healthy" and "i'm the only server left on-line". In fact, I'd like to ask for further clarification on step 3). What do you mean by "come online" - start new SARR exchanges after power up or "reach T1 timer and start renewing"? Here are my questions in case by "come online" you meant "start new SARR". Steps 1) and 2) are as you described. Primary client sends a SOLICIT that is received by secondary server. Should it respond or not? That is not described in your I-D. I tried to look for DISCOVER in RFC3074, but it doesn't seem to be described either. Section 3.1 describes what to do with messages which contain server-id, but there is no text that explains what to do with messages that doesn't have server-id. I assume it should follow RFC3315, i.e. respond as usual? Since that's the only server responding, primary client will pick it up and send REQUEST with secondary server-id. Here are 2 choices: a) secondary choses to respond to REQUEST. Address will be assigned. If the secondary server choses to answer RENEW, there won't be any cycles, but primary client will stay with secondary. If secondary server choses to not respond RENEWs, primary client will go to REBIND mode. This will be repeated over and over again, until primary server is restored. b) secondary choses to not respond to REQUEST. The primary client goes into infinite SOLCIT->ADVERTISE->REQUEST->retransmits->SOLICIT loops until primary server is restored. Note that I'm talking about situation before primary server is restored. > 4) Primary server is restored > 5) Secondary clients can Renew as the secondary server never went away > 6) Primary clients Renewing against the secondary server get ignored > 7) Primary clients transition to Rebind, where the primary server then > answers them. The clients then remember that the primary server > answered and will do future Renews to the primary. > > This is only one cycle of failed RENEW -> REBIND. This assumes that the load balancing server behaves differently depending on whether the partner is healthy or down, right? That's against what is stated in the abstract ("without exchanging any information beyond initial configuration") or there is some explanatory text is missing. In my opinion, the different behavior depending on whether the other servers are healthy or not, require a state machine definition, with clear transition rules. That's suddenly becoming much more complex than a simple load balancing. This finally brings me to another question: can this load balancing work on its own, without failover? > Security considerations section is nice, but not sufficient. You also > mention that by misconfiguring HBA, administrators can fail to service > certain group of users and finding a pattern in such a group would be > difficult. As a practical aspect, debugging off-by-1 issues would be > tricky e.g. first server handles 1-127 and the second handles 128-255 > (who is serving bucket 0?). Some warning about it - that the sum of all > Hash Bucket Assignments of all servers must cover the whole range - > would be useful. > Are these security considerations, or just potential configuration errors? Ok, fair point. Perhaps they could be moved to a separate section called Deployment Considerations or Operational Considerations? However, if you insist that these warnings are not needed, I won't object. Any comments on the load balancing on relays? I think the easiest way to resolve my concerns would be to simply remove the reference to relays from abstract and do everthing on server side. Additional comment: abstract mentions that the mechanism work "without exchanging any information beyond initial configuration". Can you elaborate on the initial configuration exchange? That's odd and I haven't found anything about in in the text. I think that's a simple copy and paste error from RFC3074 (which is also making the same mistake, but that's a different story). Tomek From volz@cisco.com Mon Jul 1 14:44:53 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 5AC3D11E82A4 for ; Mon, 1 Jul 2013 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zdSm3qgJvYr for ; Mon, 1 Jul 2013 14:44:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 772A011E82AA for ; Mon, 1 Jul 2013 14:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7019; q=dns/txt; s=iport; t=1372715063; x=1373924663; h=from:to:subject:date:message-id:mime-version; bh=hF6PN4Qkn2ylRof+JtwixyYzXxkCPEkuY1evV8/qr5I=; b=esYMxRxGSs3HABCY3hnHyAE0yZdWHCl1Pr3DHv3GH0A7sdCqzOJpvxWT CPpM5Hg+qNzzRIYv7ijaVwFSM7DHjmJAFUgRzQUBCrYmpq9dbdRGM0GDq Ar0qdeEzPxUYbg+XqpZRS2yz1t8YUUakISPdNUT8NrvjB1I9uxbgF5F+k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAEj20VGtJXHB/2dsb2JhbABagkVEMkm3AYg2fRZ0giUBBB0QXgEqViYBBBuIBwybNaAZjy2DPGMDmHGQHIMRgig X-IronPort-AV: E=Sophos;i="4.87,976,1363132800"; d="scan'208,217";a="229459314" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jul 2013 21:44:23 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r61LiNLY017187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Jul 2013 21:44:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 16:44:21 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WGLC - draft-ietf-dhc-option-guidelines-12 - Respond by July 15 Thread-Index: Ac52own5iR515kljRfWEe3bIF+k6bg== Date: Mon, 1 Jul 2013 21:44:21 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CDA1C@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.86.240.243] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185CDA1Cxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respond by July 15 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, 01 Jul 2013 21:44:53 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185CDA1Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft-ietf-dhc-option-guidelines-12, http://tools.ietf.org/html/draft-i= etf-dhc-option-guidelines-12, addresses the comments from the previous (-11= ) last call. While originally I expected to have a short (1 week) last call= for the updated document, I think it best to have the standard 2 weeks giv= en the time of year (and the Independence Day holiday in the US). Please review the draft and indicate whether or not you feel this version i= s ready to be published. Your response matters to the process, so please do= respond. Do note: While I encourage full reviews, the main focus is to assure we hav= e consensus on the recent changes from the -11. The -11 WGLC support will b= e taken into consideration. As Tomek is an author, I will evaluate consensus after July 15, 2013. - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E185CDA1Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft-ietf-dhc-option-guidelines-12, http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12, address= es the comments from the previous (-11) last call. While originally I expec= ted to have a short (1 week) last call for the updated document, I think it= best to have the standard 2 weeks given the time of year (and the Independence Day holiday in the US).<= /o:p>

 

Please review the draft and indicate whether or n= ot you feel this version is ready to be published. Your response matters to= the process, so please do respond.

 

Do note: While I encourage full reviews, the m= ain focus is to assure we have consensus on the recent changes from the -11= . The -11 WGLC support will be taken into consideration.

 

As Tomek is an author, I will evaluate consensus = after July 15, 2013.

 

-       = ;   Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E185CDA1Cxmbrcdx04ciscoc_-- From praspati@cisco.com Tue Jul 2 07:12:45 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 3810E21F9EDC for ; Tue, 2 Jul 2013 07:12:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXkYmQoHTjQq for ; Tue, 2 Jul 2013 07:12:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7928021F9E31 for ; Tue, 2 Jul 2013 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2085; q=dns/txt; s=iport; t=1372774359; x=1373983959; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VrX4g7jBeukJ0/cfKKcaWwCg1fmTTZ8iCUvv05n6ejM=; b=VXldcl27O+l+z3VSoFTL0dnlLPnwcHUVydd+KtWBMpbKNQnXlaDeiF+r kvHwndq7tl69s+uFgySF81SDNKGTMPmWZCt5ahlxTAREiiHSh6FhAt6kC 3ccq6TMlpLt5BhWuHOcW67dqwA/nfM9pHFhfkqtQie7BXnWOKij4vFdTy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAB3e0lGtJXG8/2dsb2JhbABagwl7v02BARZ0giMBAQEEOj0CEgEIGAoUQiUCBA4FCIgHvCqPKTEHgwRnA5N3lReDEYIo X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229966853" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 02 Jul 2013 14:12:39 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r62ECd9w012355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 14:12:39 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 09:12:38 -0500 From: "Prashanth Patil (praspati)" To: Ted Lemon Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaAgCD5gwCABMu2gP///s0AgAGeyIA= Date: Tue, 2 Jul 2013 14:12:38 +0000 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751F61CD@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.68.21.163] Content-Type: text/plain; charset="us-ascii" Content-ID: <94B15579BCF97945B908BFDCBD6CB6F4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 02 Jul 2013 14:12:45 -0000 Hi Ted, On 02/07/13 12:28 AM, "Ted Lemon" wrote: >(ad hat off) > >On Jul 1, 2013, at 9:32 AM, Prashanth Patil (praspati) > wrote: >> Yes, this was one of the suggestions made earlier. Notification from >>relay >> then becomes generic and not specific to DNS. The server decides >>whatever >> actions need to be done, such as reconfiguring DNS server lists. > >I'm sorry, but you did not answer my question. The question was this: > >>> Why don't you just configure the DHCP server to return DNS servers in a >>> different order for different links? Links are identified by relay >>> agent, so this gets you the precise behavior you want, but with a >>> centralized configuration file rather than with per-relay >>>configuration. > >That is, I am not suggesting this as an alternative. I am asking you >why you don't consider this to be a better alternative. > >The reason I ask is that what you are proposing is extremely harmful. >You are requiring new special protocol extension with new special-case >code to be added to the DHCP server to handle this use case, and you are >requiring that relay agents throughout the network be individually >configured to specify behavior on the DHCP server, which is a maintenance >nightmare. > >So if you want to do something this harmful, you should have a good >explanation for why it's better than the alternative. A static DNS order for different links introduces sub-optimal behavior during transitions unless the servers are re-prioritized or until the host stack re-initializes. The draft proposes that a relay indicate dynamic transitions of the host to the server which the server cannot learn otherwise or at best until the next request eg: Dual-Stack-only to IPv6-only transition. With some generalization to the proposal, a DHCP server could provide desired config updates in a more responsive manner when the relay notifies host mode changes without specifying behavior eg "Host changed from mode X to mode Y". -Prashanth > From volz@cisco.com Tue Jul 2 08:00: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 20F4E21F9F06 for ; Tue, 2 Jul 2013 08:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXRFqUOTvCoM for ; Tue, 2 Jul 2013 08:00:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E313021F9E91 for ; Tue, 2 Jul 2013 08:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15800; q=dns/txt; s=iport; t=1372777253; x=1373986853; h=from:to:subject:date:message-id:mime-version; bh=BhX5rQtby6f/e74FEmBC2ljPKWxImSsvBZjNLR1BIuE=; b=TawUP9pZVwIGfyBnEwGDhs7a3152dLsd7BFq0riaiU7hGs0doBr3nG00 QWqYWKveZzy2q2r99ahdAYY9iYUyhZEFNB6ifwZ5DVMSCjup/RZNjyGnm rehUqrscLY14v7mxbGkFnIs4Z+59cROQj3Frj/2ApBAMBSlQavxSwjSju 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFABnq0lGtJV2Y/2dsb2JhbABagkVEMkm/TYEBFnSCJQEEAQEBKjsGHQEqHS4LFBIBBBMIDId7DJtloDAEjhiBES2DD2cDqQ6DEYFxNw X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208,217";a="229770867" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jul 2013 15:00:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r62F0qTs019937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jul 2013 15:00:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 10:00:52 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Nomcom still beating bushes - Pleases consider volunteering!! Thread-Index: Ac53NH8JVsEx+0IQSFuAvQ/leQnNrQ== Date: Tue, 2 Jul 2013 15:00:51 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CF0BB@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.86.245.100] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185CF0BBxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Nomcom still beating bushes - Pleases consider volunteering!! 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, 02 Jul 2013 15:00:58 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E185CF0BBxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In case you missed it, the Nomcom is still looking for volunteers for the p= ool. Please consider submitting your name. You can send a message to nomc= om-chair-2013@ietf.org to do so. Some b= ackground about the Nomcom is at https://www.ietf.org/nomcom/. - Bernie FYI - The longer message that was recently sent is ... The IETF nominating committee (nomcom) process for 2013-14 is under way. Th= e IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time thi= s email announcement goes out to start the solicitation of volunteers. The fi= ve meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86. If you qualify, just hit Reply to this email and volunteer. :D The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularl= y scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) July 8, 2013 (deadline extended). In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Comp= any field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). You should expect an email response from me within 3 business days stating whether or not you are qualified (and added to the list). If you don't rec= eive this response, please re-send your email adding the tag "RESEND" to the subject = line. Participating in the IETF nomcom is a meaningful and fun way to contribute = to the IETF. Please help us meet a challenge we've set to have 200 volunteers. Hit Reply to this message and volunteer today. Thanks! Allison Allison Mankin 2013-2014 NOMCOM Chair _______________________________________________ Recentattendees mailing list Recentattendees@ietf.org https://www.ietf.org/mailman/listinfo/recentattendees --_000_489D13FBFA9B3E41812EA89F188F018E185CF0BBxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In case you missed it, the Nomcom is still lookin= g for volunteers for the pool.  Please consider submitting your name.&= nbsp; You can send a message to nomcom-chair-2013@ietf.org to do so.  Some background about the Nomcom is at https://www.ietf.org/nomcom/.<= o:p>

 

-     &= nbsp;    Bernie

 

FYI - The longer message that was recently sent is &= #8230;

 

The IETF nominating committee (nomcom) process fo= r 2013-14 is under way. The

IETF nomcom appoints folks to fill the open slots= on the IAOC, the IAB,

and the IESG. Ten voting members for the nomcom a= re selected in a verifiably

random way from a pool of volunteers. =

 

The details of the selection and operation of the= nomcom can be found

in RFCs 3777, 5078, 5633, 5680, and 6859.  F= our of those RFCs  (3777, 5633,

5680 and 6859)  comprise BCP 10. We will als= o reference RFC 3797.

 

Volunteers must have attended 3 of the past 5 IET= F meetings.  As specified in

RFC 3777, that means three out of the five past m= eetings up to the time this

email announcement goes out to start the solicita= tion of volunteers. The five

meetings out of which you must have attended thre= e are IETF 82, 83, 84, 85, 86.

 

If you qualify, just hit Reply to this email and = volunteer.   :D

 

The list of people and posts whose terms end with= the March 2014 IETF

meeting, and thus the positions for which this no= mcom is responsible, are

 

IAOC:

Chris Griffiths

 

IAB:

Bernard Aboba

Marc Blanchet

Ross Callon

Eliot Lear

Hannes Tschofenig

 

IESG:

Barry Leiba (Applications)

Brian Haberman (Internet)

Benoit Claise (Operations and Management)

Gonzalo Camarillo (RAI)

Stewart Bryant (Routing)

Sean Turner (Security)

Martin Stiemerling (Transport)

 

The primary activity for this nomcom will begin i= n July 2013 and should be

completed in January 2014.  Being a nomcom m= ember will require some time

commitment - there will be interviews with candid= ates at meetings, regularly

scheduled conference calls to ensure progress, co= llection and review of

requirements from the commitment, review of candi= date questionnaires and

of community feedback.  A more detailed time= table for the nomcom tasks

will appear soon.

 

Please respond to this email before 11:59 pm EDT = (UTC -4 hours)

July 8, 2013 (deadline extended).  In the bo= dy include:

1. your Given Name as you enter it when you regis= ter for the IETF

2. your Family Name as you enter it when you regi= ster for the IETF

3. your current primary affilation (the informati= on you enter into the Company field)

4. any/all email addresses you've used to registe= r for IETF meetings

5. which email address you prefer

6. your phone number (for our use in confirming y= ou if selected).

 

You should expect an email response from me withi= n 3 business days stating

whether or not you are qualified (and added to th= e list).  If you don't receive this

response, please re-send your email adding the ta= g "RESEND" to the subject line.

 

Participating in the IETF nomcom is a meaningful = and fun way to contribute to the IETF. 

Please help us meet a challenge we've set to have= 200 volunteers.

 

Hit Reply to this message and volunteer today.&nb= sp; Thanks!

 

Allison

 

Allison Mankin

2013-2014 NOMCOM Chair

_______________________________________________

Recentattendees mailing list

Recen= tattendees@ietf.org

https://www.ietf.org/mailman/listinfo/recentattendees<= o:p>

 

--_000_489D13FBFA9B3E41812EA89F188F018E185CF0BBxmbrcdx04ciscoc_-- From volz@cisco.com Tue Jul 2 09:22: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 B791221F9E21 for ; Tue, 2 Jul 2013 09:22:47 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh9T3TmT43L7 for ; Tue, 2 Jul 2013 09:22:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CF00521F9F77 for ; Tue, 2 Jul 2013 09:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3905; q=dns/txt; s=iport; t=1372782163; x=1373991763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ptasx82VoDY5rySJ6iVZj4frUeoD63ne50HhcEj2LJY=; b=js8tF9xhHJ/8MjtTmuWDrQus8xQoLZiF7XSvNOpswLu+XbeRW85skaQT KSlEU7k5vZFT7wrXAkDzIbMYKrwJn8TAsbe3ZY2kharvSirf+OtRY6j9n SOY32DYEa5awunz8yDZAc3y4CfONu83w+qunnvYNgTpLdsz5BjIQTvqCk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFABn80lGtJXHA/2dsb2JhbABagwkySb9OgQQWdIIjAQEBBAEBATc0CQIMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiAcMvCQEjykGKwcGgn5nA5N3lReDEYIo X-IronPort-AV: E=Sophos;i="4.87,981,1363132800"; d="scan'208";a="230097871" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2013 16:22:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r62GMg7D029464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 16:22:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 11:22:41 -0500 From: "Bernie Volz (volz)" To: "Prashanth Patil (praspati)" , Ted Lemon Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaAgCD5gwCABMu2gP///s0AgAGeyID//3BUAA== Date: Tue, 2 Jul 2013 16:22:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CF3B1@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B6307751F61CD@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.245.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 02 Jul 2013 16:22:48 -0000 I think they key concepts are: 1. An option from the relay during client requests (Relay-Forw) to the serv= er as to whether the client is single/dual stacked (as the assumption is th= e relay monitors this). 2. A means for the relay to reconfigure the client (already covered by Reco= nfigure-Request) when changes in the dual stack-ness for a client is detect= ed, perhaps passing this option to help the server determine what to tell t= he client about reconfiguring. I'm not sure that option adds significant va= lue and requires complicated processing by the server - but if some impleme= ntation wanted to use it, I don't see the harm (it would be a MAY). The above is also much more generalized. Whether the value here is worth it= isn't for me to decide (as it may require substantial work in the relay ag= ents). How the server deals with that relay option data to select appropriate opti= ons (or option value ordering) is out of scope? Servers have vastly differe= nt configuration mechanisms. For example, with our server this could be eas= y to do as you can use client classing to control which bundle of options t= o use (we wouldn't have to change the code, though customers would have to = write appropriate classing expressions to use the relay's option). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of P= rashanth Patil (praspati) Sent: Tuesday, July 02, 2013 10:13 AM To: Ted Lemon Cc: dhcwg@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconf= igure-01.txt Hi Ted, On 02/07/13 12:28 AM, "Ted Lemon" wrote: >(ad hat off) > >On Jul 1, 2013, at 9:32 AM, Prashanth Patil (praspati)=20 > wrote: >> Yes, this was one of the suggestions made earlier. Notification from=20 >>relay then becomes generic and not specific to DNS. The server=20 >>decides whatever actions need to be done, such as reconfiguring DNS=20 >>server lists. > >I'm sorry, but you did not answer my question. The question was this: > >>> Why don't you just configure the DHCP server to return DNS servers in a >>> different order for different links? Links are identified by relay >>> agent, so this gets you the precise behavior you want, but with a =20 >>>centralized configuration file rather than with per-relay=20 >>>configuration. > >That is, I am not suggesting this as an alternative. I am asking you >why you don't consider this to be a better alternative. > >The reason I ask is that what you are proposing is extremely harmful. >You are requiring new special protocol extension with new special-case=20 >code to be added to the DHCP server to handle this use case, and you=20 >are requiring that relay agents throughout the network be individually=20 >configured to specify behavior on the DHCP server, which is a=20 >maintenance nightmare. > >So if you want to do something this harmful, you should have a good=20 >explanation for why it's better than the alternative. A static DNS order for different links introduces sub-optimal behavior duri= ng transitions unless the servers are re-prioritized or until the host stac= k re-initializes. The draft proposes that a relay indicate dynamic transitions of the host to= the server which the server cannot learn otherwise or at best until the ne= xt request eg: Dual-Stack-only to IPv6-only transition. With some generaliz= ation to the proposal, a DHCP server could provide desired config updates i= n a more responsive manner when the relay notifies host mode changes withou= t specifying behavior eg "Host changed from mode X to mode Y". -Prashanth > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Jul 2 09:39: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 6A30D21F940D for ; Tue, 2 Jul 2013 09:39:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2qxwbH4mj-4 for ; Tue, 2 Jul 2013 09:39:09 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id AC39A21F8A85 for ; Tue, 2 Jul 2013 09:39:09 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUdMCLXou/tpM8fUbLs/xs1mRuZwczzWr@postini.com; Tue, 02 Jul 2013 09:39:09 PDT 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 F1E671B821C for ; Tue, 2 Jul 2013 09:39:08 -0700 (PDT) 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 EABD019005D; Tue, 2 Jul 2013 09:39:08 -0700 (PDT) (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; Tue, 2 Jul 2013 09:39:08 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOdCenS2HB7oYtEky7nP+0jJgy+ZlQS9sAgABa/4CAAUKZAIAAJFaAgAAEmYA= Date: Tue, 2 Jul 2013 16:39:07 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F7DA9@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751F61CD@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E185CF3B1@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185CF3B1@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="Windows-1252" Content-ID: <3F644D0D0B2B534F8782A2CE8B7A42E3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 02 Jul 2013 16:39:16 -0000 On Jul 2, 2013, at 12:22 PM, "Bernie Volz (volz)" wrote: > 1. An option from the relay during client requests (Relay-Forw) to the se= rver as to whether the client is single/dual stacked (as the assumption is = the relay monitors this). > 2. A means for the relay to reconfigure the client (already covered by Re= configure-Request) when changes in the dual stack-ness for a client is dete= cted, perhaps passing this option to help the server determine what to tell= the client about reconfiguring. I'm not sure that option adds significant = value and requires complicated processing by the server - but if some imple= mentation wanted to use it, I don't see the harm (it would be a MAY). Thanks, Bernie=97that's helpful. I guess I can see the motivation for doi= ng this, but it seems like some heavy gymnastics the entire purpose of whic= h is to get around bugs in the client stack. It's also something that a d= ual-stack DHCP server could detect on its own, if the relays implement the = client link-layer-address relay option. And it's also pretty experimental= . What's the use case? Do we have a real-world application for this, or is = it just something that is theorized to be useful in the future? From volz@cisco.com Tue Jul 2 09:51:55 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 D9AA511E80AD for ; Tue, 2 Jul 2013 09:51:55 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYxrxi8WyhpZ for ; Tue, 2 Jul 2013 09:51:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9DE21F9E24 for ; Tue, 2 Jul 2013 09:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1372783910; x=1373993510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ntCds2KPiUOq9/naYOwNfMASkp43ioPp4vJDosjtzh8=; b=CmsTp8ptoCsYGUe3xUYYK1AVh1a7zoyBFEm6/hXfhdo/EmsS3KOiFYdD jCpHeRqkQkgriNYoCh5RMQBKJVsgChtYR7zW/XUi4J5V7zuH1ATGHS3B9 IkAeIIvBPcPqs0K17/4BrFRyH4RudwkL0vXso6V6513ADp6/G0bGbu2eW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJID01GtJV2Z/2dsb2JhbABagwl7v06BBRZ0giMBAQEEOj0CDAQCAQgRBAEBAQoUCQcyFAkIAgQOBQiIB7w7jykxBwaCfmcDkzuVU4MRgig X-IronPort-AV: E=Sophos;i="4.87,981,1363132800"; d="scan'208";a="230022038" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 02 Jul 2013 16:51:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r62GpnDH021847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 16:51:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 11:51:48 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOY3uM9UALGIVfFEmPJoU9Kl4stpkq4qaAgCD5gwCABMu2gP///s0AgAGeyID//3BUAIAAXGmA//+s3eA= Date: Tue, 2 Jul 2013 16:51:47 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185CF4B7@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B6307751F61CD@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E185CF3B1@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751F7DA9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751F7DA9@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.245.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 02 Jul 2013 16:51:56 -0000 I'm not clear on the need for this myself. Is this a real problem or just a= n optimization? I just figured if there was value, that this seemed like a much more stream= lined approach. The draft didn't seem to address what happens when the clie= nt sends in requests (and making the DHCP server remember this from a recon= figure-request seemed a bit odd -- why not have the relay include this in e= ach Relay-Forw if this is 'needed'). There's also the question of whether the client itself c/should tell the se= rver this (i.e., it has a v4 address) -- if it is important. That would eli= minate the relay from having to do the monitoring. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Tuesday, July 02, 2013 12:39 PM To: Bernie Volz (volz) Cc: Prashanth Patil (praspati); dhcwg@ietf.org; Tirumaleswar Reddy (tireddy= ) Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconf= igure-01.txt On Jul 2, 2013, at 12:22 PM, "Bernie Volz (volz)" wrote: > 1. An option from the relay during client requests (Relay-Forw) to the se= rver as to whether the client is single/dual stacked (as the assumption is = the relay monitors this). > 2. A means for the relay to reconfigure the client (already covered by Re= configure-Request) when changes in the dual stack-ness for a client is dete= cted, perhaps passing this option to help the server determine what to tell= the client about reconfiguring. I'm not sure that option adds significant = value and requires complicated processing by the server - but if some imple= mentation wanted to use it, I don't see the harm (it would be a MAY). Thanks, Bernie-that's helpful. I guess I can see the motivation for doing= this, but it seems like some heavy gymnastics the entire purpose of which = is to get around bugs in the client stack. It's also something that a dua= l-stack DHCP server could detect on its own, if the relays implement the cl= ient link-layer-address relay option. And it's also pretty experimental. What's the use case? Do we have a real-world application for this, or is = it just something that is theorized to be useful in the future? From Ted.Lemon@nominum.com Tue Jul 2 09:56: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 7FC6521F9EC1 for ; Tue, 2 Jul 2013 09:56:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPP-ruJ1zobT for ; Tue, 2 Jul 2013 09:56:40 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id B9EDE21F9EB5 for ; Tue, 2 Jul 2013 09:56:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUdMGSAkFCQiqRyMj3KB71hqOlA2h03Wl@postini.com; Tue, 02 Jul 2013 09:56:40 PDT 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 644091B821E for ; Tue, 2 Jul 2013 09:56:40 -0700 (PDT) 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 5D7F419005D; Tue, 2 Jul 2013 09:56:40 -0700 (PDT) (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; Tue, 2 Jul 2013 09:56:40 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt Thread-Index: AQHOdCenS2HB7oYtEky7nP+0jJgy+ZlQS9sAgABa/4CAAUKZAIAAJFaAgAAEmYCAAAOIgIAAAVsA Date: Tue, 2 Jul 2013 16:56:39 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751F7E9A@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751F61CD@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E185CF3B1@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751F7DA9@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E185CF4B7@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185CF4B7@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: <81175454D4210B468595CB663833F9EA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.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, 02 Jul 2013 16:56:47 -0000 On Jul 2, 2013, at 12:51 PM, "Bernie Volz (volz)" wrote: > I just figured if there was value, that this seemed like a much more stre= amlined approach. The draft didn't seem to address what happens when the cl= ient sends in requests (and making the DHCP server remember this from a rec= onfigure-request seemed a bit odd -- why not have the relay include this in= each Relay-Forw if this is 'needed'). Yes. Also, why not just have an option that says "client is dual-stack, o= r not" and let the DHCP server decide what to do about it, rather than gett= ing all specific about what it does with it? > There's also the question of whether the client itself c/should tell the = server this (i.e., it has a v4 address) -- if it is important. That would e= liminate the relay from having to do the monitoring. Requires client changes, so it's understandable that we'd want to do it in = relays. Of course, there's a third unanswered question, which is "what ab= out DHCPv4?" From internet-drafts@ietf.org Wed Jul 3 12:11: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 00F4621F8B8B; Wed, 3 Jul 2013 12:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMcfX4NmTkML; Wed, 3 Jul 2013 12:11:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2754921F9C72; Wed, 3 Jul 2013 12:11:33 -0700 (PDT) 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.51.p2 Message-ID: <20130703191133.535.35456.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 12:11:33 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-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: Wed, 03 Jul 2013 19:11:40 -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 : DHCPv6 Failover Requirements Author(s) : Tomek Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-requirements-06.txt Pages : 16 Date : 2013-07-03 Abstract: The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-requireme= nts-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Wed Jul 3 13:56:59 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 8806E11E8239; Wed, 3 Jul 2013 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQr1e4fPIELE; Wed, 3 Jul 2013 13:56:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF6311E80AE; Wed, 3 Jul 2013 13:56:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Sender: Message-ID: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 13:56:58 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (DHCPv6 Failover Requirements) to Informational RFC X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 20:56:59 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv6 Failover Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-07-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. From stenc@s-carlsen.dk Wed Jul 3 17:29: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 603EB21F889C for ; Wed, 3 Jul 2013 17:29:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIb1Z5xVz9Z7 for ; Wed, 3 Jul 2013 17:29:15 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id EE09E21F841A for ; Wed, 3 Jul 2013 17:29:14 -0700 (PDT) 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 89BA8DF42 for ; Thu, 4 Jul 2013 02:29:10 +0200 (CEST) Message-ID: <51D4C1D6.6010008@s-carlsen.dk> Date: Thu, 04 Jul 2013 02:29:10 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> In-Reply-To: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------020605070902040101080404" Subject: Re: [dhcwg] Last Call: (DHCPv6 Failover Requirements) to Informational RFC 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, 04 Jul 2013 00:29:19 -0000 This is a multi-part message in MIME format. --------------020605070902040101080404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I wonder if it is beneficial to limit the failover to just two partners at this level of specification? I should think there should be freedom for people to consider the option of more than just two partners at this stage; the definition of the actual protocol could easily limit the case to just two partners until somebody comes up with a viable scheme for more than two partners. As written it will take much more effort to allow for more than two partners, should that be desired in the future. On 03/07/13 22:56, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG > (dhc) to consider the following document: > - 'DHCPv6 Failover Requirements' > as Informational > RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-07-17. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers > to operate on a single network, however it does not define any way > the servers could share information about currently active clients > and their leases. Some sites are interested in running multiple > servers in such a way as to provide increased availability in case of > server failure. In order for this to work reliably, the cooperating > primary and secondary servers must maintain a consistent database of > the lease information. [RFC3315] allows for but does not define any > redundancy or failover mechanisms. This document outlines > requirements for DHCPv6 failover, enumerates related problems, and > discusses the proposed scope of work to be conducted. This document > does not define a DHCPv6 failover protocol. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > 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!!!" --------------020605070902040101080404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I wonder if it is beneficial to limit the failover to just two partners at this level of specification? I should think there should be freedom for people to consider the option of more than just two partners at this stage; the definition of the actual protocol could easily limit the case to just two partners until somebody comes up with a viable scheme for more than two partners. As written it will take much more effort to allow for more than two partners, should that be desired in the future.


On 03/07/13 22:56, The IESG wrote:
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'DHCPv6 Failover Requirements'
  <draft-ietf-dhc-dhcpv6-failover-requirements-06.txt> as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers
   to operate on a single network, however it does not define any way
   the servers could share information about currently active clients
   and their leases.  Some sites are interested in running multiple
   servers in such a way as to provide increased availability in case of
   server failure.  In order for this to work reliably, the cooperating
   primary and secondary servers must maintain a consistent database of
   the lease information.  [RFC3315] allows for but does not define any
   redundancy or failover mechanisms.  This document outlines
   requirements for DHCPv6 failover, enumerates related problems, and
   discusses the proposed scope of work to be conducted.  This document
   does not define a DHCPv6 failover protocol.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
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!!!"
--------------020605070902040101080404-- From Ted.Lemon@nominum.com Wed Jul 3 18:08:37 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 4E8A221F9A8E for ; Wed, 3 Jul 2013 18:08:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaeoLRYGegJa for ; Wed, 3 Jul 2013 18:08:30 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5042721F9A83 for ; Wed, 3 Jul 2013 18:08:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUdTLDT5QShPaEEI8F+kPPsmQUF54Tivh@postini.com; Wed, 03 Jul 2013 18:08:30 PDT 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 AD9221B81FA for ; Wed, 3 Jul 2013 18:08:29 -0700 (PDT) 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 A6CC5190061; Wed, 3 Jul 2013 18:08:29 -0700 (PDT) (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, 3 Jul 2013 18:08:29 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] Last Call: (DHCPv6 Failover Requirements) to Informational RFC Thread-Index: AQHOeE2Vj2yZNHQw6Eq+77oq5+0sm5lUKrkA Date: Thu, 4 Jul 2013 01:08:28 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> <51D4C1D6.6010008@s-carlsen.dk> In-Reply-To: <51D4C1D6.6010008@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] Last Call: (DHCPv6 Failover Requirements) to Informational RFC 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, 04 Jul 2013 01:08:37 -0000 On Jul 3, 2013, at 8:29 PM, Sten Carlsen wrote: > I wonder if it is beneficial to limit the failover to just two partners a= t this level of specification? I should think there should be freedom for p= eople to consider the option of more than just two partners at this stage; = the definition of the actual protocol could easily limit the case to just t= wo partners until somebody comes up with a viable scheme for more than two = partners. As written it will take much more effort to allow for more than t= wo partners, should that be desired in the future. This document is a list of requirements for the failover protocol that the = DHC working group intends to develop. Its purpose is to state the goals o= f the current development effort. Why would this document prevent someone= from subsequently developing a 3-way or N-way protocol if they decided tha= t it made sense? It's not even a BCP, so it's not in any way normative. From stenc@s-carlsen.dk Thu Jul 4 07:02: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 59EC611E80E9 for ; Thu, 4 Jul 2013 07:02:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3bAkrpbkZIF for ; Thu, 4 Jul 2013 07:02:15 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5C311E80A2 for ; Thu, 4 Jul 2013 07:02:09 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id D81F0107AF; Thu, 4 Jul 2013 16:02:04 +0200 (CEST) Message-ID: <51D5805C.4020709@s-carlsen.dk> Date: Thu, 04 Jul 2013 16:02:04 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Lemon References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> <51D4C1D6.6010008@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------090201030006050505020806" Cc: "" Subject: Re: [dhcwg] Last Call: (DHCPv6 Failover Requirements) to Informational RFC 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, 04 Jul 2013 14:02:20 -0000 This is a multi-part message in MIME format. --------------090201030006050505020806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/07/13 3:08, Ted Lemon wrote: > On Jul 3, 2013, at 8:29 PM, Sten Carlsen wrote: >> I wonder if it is beneficial to limit the failover to just two partners at this level of specification? I should think there should be freedom for people to consider the option of more than just two partners at this stage; the definition of the actual protocol could easily limit the case to just two partners until somebody comes up with a viable scheme for more than two partners. As written it will take much more effort to allow for more than two partners, should that be desired in the future. > This document is a list of requirements for the failover protocol that the DHC working group intends to develop. Its purpose is to state the goals of the current development effort. Why would this document prevent someone from subsequently developing a 3-way or N-way protocol if they decided that it made sense? It's not even a BCP, so it's not in any way normative. > Well this text: ~~~~ 5. Principles of DHCPv6 Failover ....... Had there be more than two partners participating in a relationship, there would be a third states in between (some partners updated their state, but some didn't). This would greatly complicate protocol design, and would give little advantage in return. /_Therefore an approach that assumes a pair of cooperating servers was chosen_/. ~~~~ as well as the all of "7. DHCPv6 Failover Requirements" which specifically limits failover to " 1. The number of supported partners must be _exactly two_, i.e. there are _at most two servers that are aware of a specific lease._" This and more text will, I believe severely limit the developments to only look at the two server solutions. The text may not be normative but I feel sure it will be read as such. I still feel this is too limiting. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------090201030006050505020806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/07/13 3:08, Ted Lemon wrote:
On Jul 3, 2013, at 8:29 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

I wonder if it is beneficial to limit the failover to just two partners at this level of specification? I should think there should be freedom for people to consider the option of more than just two partners at this stage; the definition of the actual protocol could easily limit the case to just two partners until somebody comes up with a viable scheme for more than two partners. As written it will take much more effort to allow for more than two partners, should that be desired in the future.

This document is a list of requirements for the failover protocol that the DHC working group intends to develop.   Its purpose is to state the goals of the current development effort.   Why would this document prevent someone from subsequently developing a 3-way or N-way protocol if they decided that it made sense? It's not even a BCP, so it's not in any way normative.
Well this text:
~~~~
5. Principles of DHCPv6 Failover

.......
Had there be more than two partners participating
   in a relationship, there would be a third states in between (some
   partners updated their state, but some didn't).  This would greatly
   complicate protocol design, and would give little advantage in
   return.  Therefore an approach that assumes a pair of cooperating
   servers was chosen.
~~~~

as well as the all of "7. DHCPv6 Failover Requirements" which specifically limits failover to " 1.   The number of supported partners must be exactly two, i.e. there are at most two servers that are aware of a specific lease."

This and more text will, I believe severely limit the developments to only look at the two server solutions. The text may not be normative but I feel sure it will be read as such. I still feel this is too limiting.
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------090201030006050505020806-- From Ted.Lemon@nominum.com Thu Jul 4 07:32:29 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 7103821F9FD5 for ; Thu, 4 Jul 2013 07:32:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNxeGabvy20D for ; Thu, 4 Jul 2013 07:32:22 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1321F9F52 for ; Thu, 4 Jul 2013 07:32:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUdWHdCiJfMhNPJxgY4otZCXVN6607NLy@postini.com; Thu, 04 Jul 2013 07:32:21 PDT 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 601BA1B821C for ; Thu, 4 Jul 2013 07:32:20 -0700 (PDT) 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 47240190061; Thu, 4 Jul 2013 07:32:20 -0700 (PDT) (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, 4 Jul 2013 07:32:13 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] Last Call: (DHCPv6 Failover Requirements) to Informational RFC Thread-Index: AQHOeE2Vj2yZNHQw6Eq+77oq5+0sm5lUKrkAgADYJACAAAhqgA== Date: Thu, 4 Jul 2013 14:32:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751FD80D@mbx-01.win.nominum.com> References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> <51D4C1D6.6010008@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> <51D5805C.4020709@s-carlsen.dk> In-Reply-To: <51D5805C.4020709@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] Last Call: (DHCPv6 Failover Requirements) to Informational RFC 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, 04 Jul 2013 14:32:29 -0000 On Jul 4, 2013, at 10:02 AM, Sten Carlsen wrote: >> This document is a list of requirements for the failover protocol that t= he DHC working group intends to develop. Its purpose is to state the goal= s of the current development effort. Why would this document prevent some= one from subsequently developing a 3-way or N-way protocol if they decided = that it made sense? It's not even a BCP, so it's not in any way normative. >>=20 >>=20 > Well this text: > ~~~~ > 5. Principles of DHCPv6 Failover >=20 > ....... > Had there be more than two partners participating > in a relationship, there would be a third states in between (some > partners updated their state, but some didn't). This would greatly > complicate protocol design, and would give little advantage in > return. =20 > Therefore an approach that assumes a pair of cooperating > servers was chosen > . > ~~~~ >=20 > as well as the all of "7. DHCPv6 Failover Requirements" which specificall= y limits failover to " 1. The number of supported partners must be exactl= y two, i.e. there are at most two servers that are aware of a specific leas= e." >=20 > This and more text will, I believe severely limit the developments to onl= y look at the two server solutions. The text may not be normative but I fee= l sure it will be read as such. I still feel this is too limiting. Sten, I have no idea what substantive point you are attempting to make here= . The working group has in fact considered how to write a failover protoc= ol, and they have concluded that the current effort will focus on a two-pee= r solution, because that is easier and more efficient. If you disagree th= at it is easier, or disagree that it is more efficient, these would be vali= d points to raise, assuming you could justify them. Simply saying "the people who are working on failover in the DHC working gr= oup should consider N-way solutions rather than 2-way solutions" is not sub= stantive, in particular because the working group _has_ considered N-way so= lutions, decided not to go that way, and documented that decision in the ve= ry draft you are commenting on. You're an active participant in the DHC working group, and you did not rais= e this point during the working group last call. The only point raised on= the document during working group last call was raised by Steinar Haug; th= e document was updated to address his concern, he said he was happy, and th= e document then passed working group last call with nobody, including you, = claiming to be in the rough. So why are you raising this point now, during the IETF last call? From stenc@s-carlsen.dk Thu Jul 4 08:08: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 037AF11E812C for ; Thu, 4 Jul 2013 08:08:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah365hDn2aMd for ; Thu, 4 Jul 2013 08:08:05 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 12CE721F9FF7 for ; Thu, 4 Jul 2013 08:07:53 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (silver4-wire.s-carlsen.dk [192.168.16.130]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 2991F521F; Thu, 4 Jul 2013 17:07:48 +0200 (CEST) Message-ID: <51D58FC4.7020004@s-carlsen.dk> Date: Thu, 04 Jul 2013 17:07:48 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Lemon References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> <51D4C1D6.6010008@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> <51D5805C.4020709@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FD80D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751FD80D@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------020607010302030600030201" Cc: "" Subject: Re: [dhcwg] Last Call: (DHCPv6 Failover Requirements) to Informational RFC 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, 04 Jul 2013 15:08:12 -0000 This is a multi-part message in MIME format. --------------020607010302030600030201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/07/13 16:32, Ted Lemon wrote: > On Jul 4, 2013, at 10:02 AM, Sten Carlsen wrote: >>> This document is a list of requirements for the failover protocol that the DHC working group intends to develop. Its purpose is to state the goals of the current development effort. Why would this document prevent someone from subsequently developing a 3-way or N-way protocol if they decided that it made sense? It's not even a BCP, so it's not in any way normative. >>> >>> >> Well this text: >> ~~~~ >> 5. Principles of DHCPv6 Failover >> >> ....... >> Had there be more than two partners participating >> in a relationship, there would be a third states in between (some >> partners updated their state, but some didn't). This would greatly >> complicate protocol design, and would give little advantage in >> return. >> Therefore an approach that assumes a pair of cooperating >> servers was chosen >> . >> ~~~~ >> >> as well as the all of "7. DHCPv6 Failover Requirements" which specifically limits failover to " 1. The number of supported partners must be exactly two, i.e. there are at most two servers that are aware of a specific lease." >> >> This and more text will, I believe severely limit the developments to only look at the two server solutions. The text may not be normative but I feel sure it will be read as such. I still feel this is too limiting. > Sten, I have no idea what substantive point you are attempting to make here. The working group has in fact considered how to write a failover protocol, and they have concluded that the current effort will focus on a two-peer solution, because that is easier and more efficient. If you disagree that it is easier, or disagree that it is more efficient, these would be valid points to raise, assuming you could justify them. > > Simply saying "the people who are working on failover in the DHC working group should consider N-way solutions rather than 2-way solutions" is not substantive, in particular because the working group _has_ considered N-way solutions, decided not to go that way, and documented that decision in the very draft you are commenting on. > > You're an active participant in the DHC working group, and you did not raise this point during the working group last call. The only point raised on the document during working group last call was raised by Steinar Haug; the document was updated to address his concern, he said he was happy, and the document then passed working group last call with nobody, including you, claiming to be in the rough. > > So why are you raising this point now, during the IETF last call? I took the opportunity to read the full length document one last time, probably late. Then it ocurred to me that the wording would seem to prohibit later efforts to look at N-way failover. I had no intention to say the working group should go with anything else but a 2-way approach as that obviously is easier and has served IPv4 well. If you don't think the above text will prohibit future N-way development, I am happy. I wish I had more time to spend here but other tasks are also calling. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------020607010302030600030201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/07/13 16:32, Ted Lemon wrote:
On Jul 4, 2013, at 10:02 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

This document is a list of requirements for the failover protocol that the DHC working group intends to develop.   Its purpose is to state the goals of the current development effort.   Why would this document prevent someone from subsequently developing a 3-way or N-way protocol if they decided that it made sense? It's not even a BCP, so it's not in any way normative.



Well this text:
~~~~
5. Principles of DHCPv6 Failover

.......
Had there be more than two partners participating
   in a relationship, there would be a third states in between (some
   partners updated their state, but some didn't).  This would greatly
   complicate protocol design, and would give little advantage in
   return.  
Therefore an approach that assumes a pair of cooperating
   servers was chosen
.
~~~~

as well as the all of "7. DHCPv6 Failover Requirements" which specifically limits failover to " 1.   The number of supported partners must be exactly two, i.e. there are at most two servers that are aware of a specific lease."

This and more text will, I believe severely limit the developments to only look at the two server solutions. The text may not be normative but I feel sure it will be read as such. I still feel this is too limiting.

Sten, I have no idea what substantive point you are attempting to make here.   The working group has in fact considered how to write a failover protocol, and they have concluded that the current effort will focus on a two-peer solution, because that is easier and more efficient.   If you disagree that it is easier, or disagree that it is more efficient, these would be valid points to raise, assuming you could justify them.

Simply saying "the people who are working on failover in the DHC working group should consider N-way solutions rather than 2-way solutions" is not substantive, in particular because the working group _has_ considered N-way solutions, decided not to go that way, and documented that decision in the very draft you are commenting on.

You're an active participant in the DHC working group, and you did not raise this point during the working group last call.   The only point raised on the document during working group last call was raised by Steinar Haug; the document was updated to address his concern, he said he was happy, and the document then passed working group last call with nobody, including you, claiming to be in the rough.

So why are you raising this point now, during the IETF last call?
I took the opportunity to read the full length document one last time, probably late. Then it ocurred to me that the wording would seem to prohibit later efforts to look at N-way failover. I had no intention to say the working group should go with anything else but a 2-way approach as that obviously is easier and has served IPv4 well.

If you don't think the above text will prohibit future N-way development, I am happy.

I wish I had more time to spend here but other tasks are also calling.

    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------020607010302030600030201--

From Ted.Lemon@nominum.com  Thu Jul  4 08:21:14 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 ABBBD21F9FDF for ; Thu,  4 Jul 2013 08:21:13 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpjWN-7QI0Qr for ; Thu,  4 Jul 2013 08:21:07 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id F22D021F9F55 for ; Thu,  4 Jul 2013 08:21:06 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUdWS4ZQx+KIBWQzFAb1T/KaQvPQiYqei@postini.com; Thu, 04 Jul 2013 08:21:07 PDT
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 583441B821C for ; Thu,  4 Jul 2013 08:21:03 -0700 (PDT)
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 E39A9190061; Thu,  4 Jul 2013 08:21:01 -0700 (PDT) (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, 4 Jul 2013 08:21:01 -0700
From: Ted Lemon 
To: Sten Carlsen 
Thread-Topic: [dhcwg] Last Call:  (DHCPv6 Failover Requirements) to Informational RFC
Thread-Index: AQHOeE2Vj2yZNHQw6Eq+77oq5+0sm5lUKrkAgADYJACAAAhqgIAACfMAgAADsAA=
Date: Thu, 4 Jul 2013 15:21:00 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751FD923@mbx-01.win.nominum.com>
References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> <51D4C1D6.6010008@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> <51D5805C.4020709@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FD80D@mbx-01.win.nominum.com> <51D58FC4.7020004@s-carlsen.dk>
In-Reply-To: <51D58FC4.7020004@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: <86CD529C71DBC44A9E74FE89036CACBF@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [dhcwg] Last Call:  (DHCPv6 Failover Requirements) to Informational RFC
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, 04 Jul 2013 15:21:14 -0000

On Jul 4, 2013, at 11:07 AM, Sten Carlsen  wrote:
> If you don't think the above text will prohibit future N-way development,=
 I am happy.

Okay, thanks.   The document is informational, so it doesn't place any requ=
irements on anyone regarding anything.   So in fact the text does not preve=
nt future n-way development.   It's just the working group saying "here is =
the functionality we intend to try to deliver."


From stenc@s-carlsen.dk  Thu Jul  4 08:27: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 219A121F9E9B for ; Thu,  4 Jul 2013 08:27:13 -0700 (PDT)
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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO6dQPTBw4FE for ; Thu,  4 Jul 2013 08:27:08 -0700 (PDT)
Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8F35F11E8133 for ; Thu,  4 Jul 2013 08:27:01 -0700 (PDT)
Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 79012521F; Thu,  4 Jul 2013 17:26:57 +0200 (CEST)
Message-ID: <51D59440.8070403@s-carlsen.dk>
Date: Thu, 04 Jul 2013 17:26:56 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ted Lemon 
References: <20130703205658.7140.2075.idtracker@ietfa.amsl.com> <51D4C1D6.6010008@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FBD27@mbx-01.win.nominum.com> <51D5805C.4020709@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FD80D@mbx-01.win.nominum.com> <51D58FC4.7020004@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307751FD923@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751FD923@mbx-01.win.nominum.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------000400050400050905030408"
Cc: "" 
Subject: Re: [dhcwg] Last Call:  (DHCPv6 Failover Requirements) to Informational RFC
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, 04 Jul 2013 15:27:13 -0000

This is a multi-part message in MIME format.
--------------000400050400050905030408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ok, my head, being normally kept in a non-English speaking nation, did
not feel certain about that fact. Sorry for the noise.


On 04/07/13 17:21, Ted Lemon wrote:
> On Jul 4, 2013, at 11:07 AM, Sten Carlsen  wrote:
>> If you don't think the above text will prohibit future N-way development, I am happy.
> Okay, thanks.   The document is informational, so it doesn't place any requirements on anyone regarding anything.   So in fact the text does not prevent future n-way development.   It's just the working group saying "here is the functionality we intend to try to deliver."
>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------000400050400050905030408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ok, my head, being normally kept in a non-English speaking nation,
    did not feel certain about that fact. Sorry for the noise.

    

    

    
On 04/07/13 17:21, Ted Lemon wrote:

    

    

      
On Jul 4, 2013, at 11:07 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:


      

        
If you don't think the above text will prohibit future N-way development, I am happy.


      

      
Okay, thanks.   The document is informational, so it doesn't place any requirements on anyone regarding anything.   So in fact the text does not prevent future n-way development.   It's just the working group saying "here is the functionality we intend to try to deliver."



    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------000400050400050905030408--

From meng.wei2@zte.com.cn  Thu Jul  4 18:37:55 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 3B0DB11E81C0 for ; Thu,  4 Jul 2013 18:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.109
X-Spam-Level: 
X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4ud2ctWHfft for ; Thu,  4 Jul 2013 18:37:50 -0700 (PDT)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CB16A11E81D5 for ; Thu,  4 Jul 2013 18:37:49 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id D40E41259D71; Fri,  5 Jul 2013 09:37:23 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r651bHU7004081; Fri, 5 Jul 2013 09:37:19 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn)
In-Reply-To: <51D614F6.4030000@isi.edu>
To: dhcwg@ietf.org
MIME-Version: 1.0
X-KeepSent: F2C8A700:C399609F-48257B9F:000725E1; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: meng.wei2@zte.com.cn
Date: Fri, 5 Jul 2013 09:37:12 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-05 09:37:25, Serialize complete at 2013-07-05 09:37:25
Content-Type: multipart/alternative; boundary="=_alternative 0008FC2148257B9F_="
X-MAIL: mse02.zte.com.cn r651bHU7004081
Cc: yong@csnet1.cs.tsinghua.edu.cn, sunqibupt@gmail.com
Subject: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
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, 05 Jul 2013 01:37:55 -0000

This is a multipart message in MIME format.
--=_alternative 0008FC2148257B9F_=
Content-Type: text/plain; charset="US-ASCII"

Hi,
        Here are some comments on this draft.
        The behaviours of Client/Relay/Sever seem to be lack of specific 
messages. 
    For example, DHCPv4 messages, 
DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK 
    message, how to interact with DHCPv6 messages 
SOLICIT/ADVERTISE/REQUEST/CONFIRM/
    RENEW/RELEASE/DECLINE message (as a option of DHCPv6). 
        By the way, interaction process of messages might be included in 
the document.
 
Cheers,
Wei
--=_alternative 0008FC2148257B9F_=
Content-Type: text/html; charset="US-ASCII"



Hi,

        Here are
some comments on this draft.

        The behaviours
of Client/Relay/Sever seem to be lack of specific messages. 

    For example, DHCPv4 messages,
DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK 

    message, how to interact
with DHCPv6 messages SOLICIT/ADVERTISE/REQUEST/CONFIRM/

    RENEW/RELEASE/DECLINE
message (as a option of DHCPv6). 

        By the way,
interaction process of messages might be included in the document.

 




Cheers,


Wei
--=_alternative 0008FC2148257B9F_=--

From volz@cisco.com  Thu Jul  4 20:17:31 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 082BC11E80F1 for ; Thu,  4 Jul 2013 20:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JRSVJXwdv0F for ; Thu,  4 Jul 2013 20:17:26 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB5E11E821D for ; Thu,  4 Jul 2013 20:17:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3292; q=dns/txt; s=iport; t=1372994244; x=1374203844; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NK6NLD/V+tFIPf91Be8RsMHv1C1Gtt7+vvuL4pOUsuY=; b=fJu0sR6RDQnOEoUa5MoTgdOvD7Ajjq3dwPotVCflrthAwlFyQ070ookT /HaeJXskbAwp7cca3JUvIices5AnARaphLsLKd074r7qwijJL8oZv9hoM jlbXmxFDY8FmrbD2P0cV9I/JqzxZtrolBEnQ/gM7DCTim/Vn0hmhqyot5 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmIFAFA61lGtJXHB/2dsb2JhbABagkVEMsECgQEWdIIkAQEEAQEBawsQAgEIBDEKBycLFBECBA4FiA8MuSEEj2cEB4MEaQOXSZFFgxE
X-IronPort-AV: E=Sophos;i="4.87,999,1363132800";  d="scan'208,217";a="230947349"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jul 2013 03:17:24 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r653HNPj009555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 03:17:23 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 22:17:23 -0500
From: "Bernie Volz (volz)" 
To: "meng.wei2@zte.com.cn" 
Thread-Topic: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
Thread-Index: AQHOeSBIdmguoor1Q0eQYtwlfbffNZlVahNk
Date: Fri, 5 Jul 2013 03:17:22 +0000
Message-ID: <3EA27ECE-BF8C-47B2-954C-B0ED84712C18@cisco.com>
References: <51D614F6.4030000@isi.edu>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_3EA27ECEBF8C47B2954CB0ED84712C18ciscocom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" , "yong@csnet1.cs.tsinghua.edu.cn" , "sunqibupt@gmail.com" 
Subject: Re: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
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, 05 Jul 2013 03:17:31 -0000

--_000_3EA27ECEBF8C47B2954CB0ED84712C18ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Huh? There is no interaction - these new messages contain normal dhcpv4 mes=
sages.

- Bernie (from iPad)

On Jul 4, 2013, at 9:38 PM, "meng.wei2@zte.com.cn" > wrote:


Hi,
        Here are some comments on this draft.
        The behaviours of Client/Relay/Sever seem to be lack of specific me=
ssages.
    For example, DHCPv4 messages, DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPAC=
K/DHCPNAK
    message, how to interact with DHCPv6 messages SOLICIT/ADVERTISE/REQUEST=
/CONFIRM/
    RENEW/RELEASE/DECLINE message (as a option of DHCPv6).
        By the way, interaction process of messages might be included in th=
e document.

Cheers,

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

--_000_3EA27ECEBF8C47B2954CB0ED84712C18ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Huh? There is no interaction - these new messages contain normal dhcpv=
4 messages.



- Bernie (from iPad)




On Jul 4, 2013, at 9:38 PM, "m=
eng.wei2@zte.com.cn" <m=
eng.wei2@zte.com.cn> wrote:










Hi, 

        Here are s=
ome comments on this draft.


        The behavi=
ours of Client/Relay/Sever seem to be lack of specific messages.


    For example, DHCPv4 mess=
ages, DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK


    message, how to interact=
 with DHCPv6 messages SOLICIT/ADVERTISE/REQUEST/CONFIRM/


    RENEW/RELEASE/DECLINE me=
ssage (as a option of DHCPv6).


        By the way=
, interaction process of messages might be included in the document.


 





Cheers,







Wei






_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg








--_000_3EA27ECEBF8C47B2954CB0ED84712C18ciscocom_--

From meng.wei2@zte.com.cn  Thu Jul  4 20:35:00 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 45FC111E80F0 for ; Thu,  4 Jul 2013 20:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.752
X-Spam-Level: 
X-Spam-Status: No, score=-99.752 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id areH1dAeqUj7 for ; Thu,  4 Jul 2013 20:34:56 -0700 (PDT)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3911E80E1 for ; Thu,  4 Jul 2013 20:34:55 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id D0F7E125BCB9 for ; Fri,  5 Jul 2013 11:34:29 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 95BE9CE4A83; Fri,  5 Jul 2013 11:34:28 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r653YP9g070292; Fri, 5 Jul 2013 11:34:25 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn)
In-Reply-To: <3EA27ECE-BF8C-47B2-954C-B0ED84712C18@cisco.com>
To: "Bernie Volz (volz)" 
MIME-Version: 1.0
X-KeepSent: 68F7A931:B21C23A3-48257B9F:00122B06; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: meng.wei2@zte.com.cn
Date: Fri, 5 Jul 2013 11:34:20 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-05 11:34:30, Serialize complete at 2013-07-05 11:34:30
Content-Type: multipart/alternative; boundary="=_alternative 0013B53648257B9F_="
X-MAIL: mse01.zte.com.cn r653YP9g070292
Cc: "dhcwg@ietf.org" , "yong@csnet1.cs.tsinghua.edu.cn" , "sunqibupt@gmail.com" 
Subject: Re: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
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, 05 Jul 2013 03:35:00 -0000

This is a multipart message in MIME format.
--=_alternative 0013B53648257B9F_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

Rm9yIGV4YW1wbGWjrCBjbGllbnQgZ2VuZXJhdGVzIERIQ1B2NCBESVNDT1ZFUiBtZXNzYWdlIGFu
ZCBlbWJlZCBpdCBhcyBhIA0Kb3B0aW9uIGludG8NCkRIQ1B2NiBTT0xJQ0lUIG1lc3NhZ2UuICBJ
dCBpcyBuYW1lZCBhcyAiREhDUHY0IERJU0NPVkVSIG92ZXIgREhDUHY2IA0KU09MSUNJVCINCmFs
c28gIkRIQ1B2NCBvdmVyIFJFTEFZLUZPUlciLyAgIkRIQ1B2NCBPRkZFUiBvdmVyIERIQ1B2NiBB
RFZFUlRJU0UiIGFuZCANCnNvIG9uLg0KDQpUaGFua3MuDQoNCg0KIkJlcm5pZSBWb2x6ICh2b2x6
KSIgPHZvbHpAY2lzY28uY29tPiDQtNPaIDIwMTMtMDctMDUgMTE6MTc6MjI6DQoNCj4gSHVoPyBU
aGVyZSBpcyBubyBpbnRlcmFjdGlvbiAtIHRoZXNlIG5ldyBtZXNzYWdlcyBjb250YWluIG5vcm1h
bCANCj4gZGhjcHY0IG1lc3NhZ2VzLg0KPiANCj4gLSBCZXJuaWUgKGZyb20gaVBhZCkNCj4gDQo+
IE9uIEp1bCA0LCAyMDEzLCBhdCA5OjM4IFBNLCAibWVuZy53ZWkyQHp0ZS5jb20uY24iIDxtZW5n
LndlaTJAenRlLmNvbS5jbg0KPiA+IHdyb3RlOg0KDQo+IA0KPiBIaSwgDQo+ICAgICAgICAgSGVy
ZSBhcmUgc29tZSBjb21tZW50cyBvbiB0aGlzIGRyYWZ0LiANCj4gICAgICAgICBUaGUgYmVoYXZp
b3VycyBvZiBDbGllbnQvUmVsYXkvU2V2ZXIgc2VlbSB0byBiZSBsYWNrIG9mIA0KPiBzcGVjaWZp
YyBtZXNzYWdlcy4gDQo+ICAgICBGb3IgZXhhbXBsZSwgREhDUHY0IG1lc3NhZ2VzLCANCj4gREhD
UERJU0NPVkVSL0RIQ1BPRkZFUi9ESENQUkVRVUVTVC9ESENQQUNLL0RIQ1BOQUsgDQo+ICAgICBt
ZXNzYWdlLCBob3cgdG8gaW50ZXJhY3Qgd2l0aCBESENQdjYgbWVzc2FnZXMgDQo+IFNPTElDSVQv
QURWRVJUSVNFL1JFUVVFU1QvQ09ORklSTS8gDQo+ICAgICBSRU5FVy9SRUxFQVNFL0RFQ0xJTkUg
bWVzc2FnZSAoYXMgYSBvcHRpb24gb2YgREhDUHY2KS4gDQo+ICAgICAgICAgQnkgdGhlIHdheSwg
aW50ZXJhY3Rpb24gcHJvY2VzcyBvZiBtZXNzYWdlcyBtaWdodCBiZSANCj4gaW5jbHVkZWQgaW4g
dGhlIGRvY3VtZW50LiANCj4gDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiANCj4gV2VpDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRoY3dnIG1haWxp
bmcgbGlzdA0KPiBkaGN3Z0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RoY3dnDQo=
--=_alternative 0013B53648257B9F_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZvciBleGFtcGxlo6wgY2xpZW50
IGdlbmVyYXRlcyBESENQdjQNCkRJU0NPVkVSIG1lc3NhZ2UgYW5kIGVtYmVkIGl0IGFzIGEgb3B0
aW9uIGludG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRIQ1B2
NiBTT0xJQ0lUIG1lc3NhZ2UuICZuYnNwO0l0IGlzDQpuYW1lZCBhcyAmcXVvdDtESENQdjQgRElT
Q09WRVIgb3ZlciBESENQdjYgU09MSUNJVCZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+YWxzbyAmcXVvdDtESENQdjQgb3ZlciBSRUxBWS1GT1JXJnF1b3Q7
Lw0KJm5ic3A7JnF1b3Q7REhDUHY0IE9GRkVSIG92ZXIgREhDUHY2IEFEVkVSVElTRSZxdW90OyBh
bmQgc28gb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5UaGFua3MuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7
QmVybmllIFZvbHogKHZvbHopJnF1b3Q7ICZsdDt2b2x6QGNpc2NvLmNvbSZndDsNCtC009ogMjAx
My0wNy0wNSAxMToxNzoyMjo8YnI+DQo8YnI+DQomZ3Q7IEh1aD8gVGhlcmUgaXMgbm8gaW50ZXJh
Y3Rpb24gLSB0aGVzZSBuZXcgbWVzc2FnZXMgY29udGFpbiBub3JtYWwgPGJyPg0KJmd0OyBkaGNw
djQgbWVzc2FnZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0gQmVybmllIChmcm9tIGlQYWQpPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgT24gSnVsIDQs
IDIwMTMsIGF0IDk6MzggUE0sICZxdW90O21lbmcud2VpMkB6dGUuY29tLmNuJnF1b3Q7ICZsdDtt
ZW5nLndlaTJAenRlLmNvbS5jbjxicj4NCiZndDsgJmd0OyB3cm90ZTo8YnI+DQo8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIaSwgPGJyPg0KJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSGVyZSBhcmUgc29tZSBjb21tZW50cyBvbiB0aGlz
IGRyYWZ0Lg0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIGJlaGF2
aW91cnMgb2YgQ2xpZW50L1JlbGF5L1NldmVyIHNlZW0NCnRvIGJlIGxhY2sgb2YgPGJyPg0KJmd0
OyBzcGVjaWZpYyBtZXNzYWdlcy4gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEZvciBleGFtcGxl
LCBESENQdjQgbWVzc2FnZXMsIDxicj4NCiZndDsgREhDUERJU0NPVkVSL0RIQ1BPRkZFUi9ESENQ
UkVRVUVTVC9ESENQQUNLL0RIQ1BOQUsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IG1lc3NhZ2Us
IGhvdyB0byBpbnRlcmFjdCB3aXRoIERIQ1B2NiBtZXNzYWdlcyA8YnI+DQomZ3Q7IFNPTElDSVQv
QURWRVJUSVNFL1JFUVVFU1QvQ09ORklSTS8gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFJFTkVX
L1JFTEVBU0UvREVDTElORSBtZXNzYWdlIChhcyBhIG9wdGlvbiBvZiBESENQdjYpLg0KPGJyPg0K
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQnkgdGhlIHdheSwgaW50ZXJhY3Rpb24g
cHJvY2VzcyBvZiBtZXNzYWdlcw0KbWlnaHQgYmUgPGJyPg0KJmd0OyBpbmNsdWRlZCBpbiB0aGUg
ZG9jdW1lbnQuIDxicj4NCiZndDsgJm5ic3A7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Jmd0OyA8YnI+DQomZ3Q7IENoZWVycyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlaTwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgZGhjd2cgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBkaGN3Z0Bp
ZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
aGN3ZzwvZm9udD48L3R0Pg0K
--=_alternative 0013B53648257B9F_=--

From gnocuil@gmail.com  Thu Jul  4 20:41: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 D071E11E80F0 for ; Thu,  4 Jul 2013 20:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.149
X-Spam-Level: 
X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45,  NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLUDLoXAO6WZ for ; Thu,  4 Jul 2013 20:41:20 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8A01911E80E1 for ; Thu,  4 Jul 2013 20:41:19 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id q56so1594980wes.3 for ; Thu, 04 Jul 2013 20:41:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N7VrrSfOTYR/Y/sym+fgnAp4eGxB3WRqRYhRpcc4SGM=; b=ASn3klniJRCizrHvoh3Vs5ipOzSvFer5UfwJNp12o/3+i4u5rRQ3ym16Ol4x+3DuWw e8WSZR5Irzy4KiEK0IeRICi/tlC6qsdLDlJ9DCBaRvgX9CtgTHDmEGrKMcVrWD7fqCQR mxb5lVUZ0Lw7JfUSj8NiKqrBR3QlLmIKnNxryu3tUu0L0Mlzi9yq2THYG+RxVBNn5jnv qkqpGpcHQBelzOPmZDgzdAEEedLLSzletVGtW2iJZgPpS0Ls25njeXbznmc5mcY15kWZ K/votvwF0zoReAVFC/4y1kjF/R6ng4ICOpThQz1uxrpPT2WHMxGgzmcYWbt47dG9XHP4 m2FA==
X-Received: by 10.180.11.146 with SMTP id q18mr3539985wib.50.1372995678704; Thu, 04 Jul 2013 20:41:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.10.67 with HTTP; Thu, 4 Jul 2013 20:40:58 -0700 (PDT)
In-Reply-To: 
References: <3EA27ECE-BF8C-47B2-954C-B0ED84712C18@cisco.com> 
From: Cong Liu 
Date: Fri, 5 Jul 2013 11:40:58 +0800
Message-ID: 
To: meng.wei2@zte.com.cn
Content-Type: multipart/alternative; boundary=001a11c24d16b51c1104e0bb7726
Cc: "dhcwg@ietf.org" , "sunqibupt@gmail.com" , "Bernie Volz \(volz\)" , "yong@csnet1.cs.tsinghua.edu.cn" 
Subject: Re: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
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, 05 Jul 2013 03:41:20 -0000

--001a11c24d16b51c1104e0bb7726
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Wei,

There are 2 new DHCPv6 messages (BOOTREQUESTV6 & BOOTREPLYV6) defined in
the draft. The BOOTP Message Option (which contains DHCPv4 message) can
only be carried in the new defined messages.

Best Wishes,
Cong


2013/7/5 

>
> For example=A3=AC client generates DHCPv4 DISCOVER message and embed it a=
s a
> option into
> DHCPv6 SOLICIT message.  It is named as "DHCPv4 DISCOVER over DHCPv6
> SOLICIT"
> also "DHCPv4 over RELAY-FORW"/  "DHCPv4 OFFER over DHCPv6 ADVERTISE" and
> so on.
>
> Thanks.
>
>
> "Bernie Volz (volz)"  =D0=B4=D3=DA 2013-07-05 11:17:22:
>
>
> > Huh? There is no interaction - these new messages contain normal
> > dhcpv4 messages.
> >
> > - Bernie (from iPad)
>
> >
> > On Jul 4, 2013, at 9:38 PM, "meng.wei2@zte.com.cn"  > > wrote:
>
> >
> > Hi,
> >         Here are some comments on this draft.
> >         The behaviours of Client/Relay/Sever seem to be lack of
> > specific messages.
> >     For example, DHCPv4 messages,
> > DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK
> >     message, how to interact with DHCPv6 messages
> > SOLICIT/ADVERTISE/REQUEST/CONFIRM/
> >     RENEW/RELEASE/DECLINE message (as a option of DHCPv6).
> >         By the way, interaction process of messages might be
> > included in the document.
> >
> >
> > Cheers,
> >
> >
> > Wei
> > _______________________________________________
> > 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
>
>

--001a11c24d16b51c1104e0bb7726
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Wei,

There are 2 new DHCPv6 messages (BOOTREQUESTV6 & BOOTREPLYV6) defined in the draft. The BOOTP Message Option (which contains DHCPv4 message) can only =
be carried in the new defined messages. 




Best Wishes,
Cong



2013/7/5  <meng.wei2@zte.com.cn=
>




For example=A3=AC client generates DHCPv4
DISCOVER message and embed it as a option into

DHCPv6 SOLICIT message.  It is
named as "DHCPv4 DISCOVER over DHCPv6 SOLICIT"

also "DHCPv4 over RELAY-FORW"/
 "DHCPv4 OFFER over DHCPv6 ADVERTISE" and so on.



Thanks.





"Bernie Volz (volz)" <volz@cisco.com>
=D0=B4=D3=DA 2013-07-05 11:17:22:




> Huh? There is no interaction - these new messages contain normal 

> dhcpv4 messages.

> 

> - Bernie (from iPad)


> 

> On Jul 4, 2013, at 9:38 PM, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn

> > wrote:



> 

> Hi, 

>         Here are some comments on this draft.


>         The behaviours of Client/Relay/Sever seem
to be lack of 

> specific messages. 

>     For example, DHCPv4 messages, 

> DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK 

>     message, how to interact with DHCPv6 messages 

> SOLICIT/ADVERTISE/REQUEST/CONFIRM/ 

>     RENEW/RELEASE/DECLINE message (as a option of DHCPv6).


>         By the way, interaction process of message=
s
might be 

> included in the document. 

>   

> 

> Cheers,

> 

> 

> Wei

> _______________________________________________

> dhcwg mailing list

> dhcwg@ietf.org=


> https://www.ietf.org/mailman/listinfo/dhcwg


_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/dhcwg





--001a11c24d16b51c1104e0bb7726--

From internet-drafts@ietf.org  Thu Jul  4 20:44: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 8773821F918F; Thu,  4 Jul 2013 20:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWMD8zVPcsxB; Thu,  4 Jul 2013 20:44:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2922821F8647; Thu,  4 Jul 2013 20:44:27 -0700 (PDT)
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.51.p2
Message-ID: <20130705034427.6565.7810.idtracker@ietfa.amsl.com>
Date: Thu, 04 Jul 2013 20:44:27 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-13.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, 05 Jul 2013 03:44:27 -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 Agent
	Author(s)       : Leaf Y. Yeh
                          Mohamed Boucadair
	Filename        : draft-ietf-dhc-dhcpv6-radius-opt-13.txt
	Pages           : 11
	Date            : 2013-07-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-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-13


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


From meng.wei2@zte.com.cn  Thu Jul  4 23:52:01 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 8D0AF21F9E5B for ; Thu,  4 Jul 2013 23:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.845
X-Spam-Level: 
X-Spam-Status: No, score=-100.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95HdIv6Qwkfm for ; Thu,  4 Jul 2013 23:51:53 -0700 (PDT)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A40A821F9E20 for ; Thu,  4 Jul 2013 23:51:49 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 72FA4A23BB for ; Fri,  5 Jul 2013 14:51:17 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 4D17274337E; Fri,  5 Jul 2013 14:51:16 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r656oEXE051060; Fri, 5 Jul 2013 14:50:14 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn)
In-Reply-To: 
To: Cong Liu 
MIME-Version: 1.0
X-KeepSent: AE245B3A:30CCDF74-48257B9F:0023EB32; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: meng.wei2@zte.com.cn
Date: Fri, 5 Jul 2013 14:50:11 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-05 14:50:21, Serialize complete at 2013-07-05 14:50:21
Content-Type: multipart/alternative; boundary="=_alternative 0025A38348257B9F_="
X-MAIL: mse02.zte.com.cn r656oEXE051060
Cc: "dhcwg@ietf.org" , "yong@csnet1.cs.tsinghua.edu.cn" , "Bernie Volz \(volz\)" , "sunqibupt@gmail.com" 
Subject: Re: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
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, 05 Jul 2013 06:52:04 -0000

This is a multipart message in MIME format.
--=_alternative 0025A38348257B9F_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgQ29uZ6OsDQoNCiAgICAgIEdvdCBpdC4gDQogICAgICBCdXQgd2h5IGRlZmluZSAyIG5ldyAi
bXNnLXR5cGUicyBpbnN0ZWFkIG9mIGV4aXN0aW5nIG1zZy10eXBlPyANCiAgICBJZiBkZWZpbmUg
IkJPT1RQIE1lc3NhZ2UgT3B0aW9uIiB3aXRoIGV4aXN0aW5nIERIQ1B2NiAibXNnLXR5cGUicywg
DQogICAgaXQgd291bGQgZ2V0IElQdjQvSVB2NiBhZGRyZXNzZXMgYXQgdGhlIHNhbWUgdGltZSBh
bmQgaW4gb25lIHByb2Nlc3MuDQoNCkNoZWVycywNCldlaQ0KDQoNCg0KDQoNCkNvbmcgTGl1IDxn
bm9jdWlsQGdtYWlsLmNvbT4gIDIwMTMtMDctMDUgMTE6NDA6NTg6DQoNCj4gSGkgV2VpLA0KPiAN
Cj4gVGhlcmUgYXJlIDIgbmV3IERIQ1B2NiBtZXNzYWdlcyAoQk9PVFJFUVVFU1RWNiAmIEJPT1RS
RVBMWVY2KSANCj4gZGVmaW5lZCBpbiB0aGUgZHJhZnQuIFRoZSBCT09UUCBNZXNzYWdlIE9wdGlv
biAod2hpY2ggY29udGFpbnMgDQo+IERIQ1B2NCBtZXNzYWdlKSBjYW4gb25seSBiZSBjYXJyaWVk
IGluIHRoZSBuZXcgZGVmaW5lZCBtZXNzYWdlcy4gDQo+IA0KPiBCZXN0IFdpc2hlcywNCj4gQ29u
Zw0KPiANCg0KPiAyMDEzLzcvNSA8bWVuZy53ZWkyQHp0ZS5jb20uY24+DQo+IA0KPiBGb3IgZXhh
bXBsZaOsIGNsaWVudCBnZW5lcmF0ZXMgREhDUHY0IERJU0NPVkVSIG1lc3NhZ2UgYW5kIGVtYmVk
IGl0IA0KPiBhcyBhIG9wdGlvbiBpbnRvIA0KPiBESENQdjYgU09MSUNJVCBtZXNzYWdlLiAgSXQg
aXMgbmFtZWQgYXMgIkRIQ1B2NCBESVNDT1ZFUiBvdmVyIA0KREhDUHY2U09MSUNJVCIgDQo+IGFs
c28gIkRIQ1B2NCBvdmVyIFJFTEFZLUZPUlciLyAgIkRIQ1B2NCBPRkZFUiBvdmVyIERIQ1B2NiBB
RFZFUlRJU0UiDQo+IGFuZCBzbyBvbi4gDQo+IA0KPiBUaGFua3MuIA0KPiANCj4gDQo+ICJCZXJu
aWUgVm9seiAodm9seikiIDx2b2x6QGNpc2NvLmNvbT4gIDIwMTMtMDctMDUgMTE6MTc6MjI6DQo+
IA0KPiANCj4gPiBIdWg/IFRoZXJlIGlzIG5vIGludGVyYWN0aW9uIC0gdGhlc2UgbmV3IG1lc3Nh
Z2VzIGNvbnRhaW4gbm9ybWFsIA0KPiA+IGRoY3B2NCBtZXNzYWdlcy4NCj4gPiANCj4gPiAtIEJl
cm5pZSAoZnJvbSBpUGFkKQ0KPiANCj4gPiANCj4gPiBPbiBKdWwgNCwgMjAxMywgYXQgOTozOCBQ
TSwgIm1lbmcud2VpMkB6dGUuY29tLmNuIiANCjxtZW5nLndlaTJAenRlLmNvbS5jbg0KPiA+ID4g
d3JvdGU6DQo+IA0KPiA+IA0KPiA+IEhpLCANCj4gPiAgICAgICAgIEhlcmUgYXJlIHNvbWUgY29t
bWVudHMgb24gdGhpcyBkcmFmdC4gDQo+ID4gICAgICAgICBUaGUgYmVoYXZpb3VycyBvZiBDbGll
bnQvUmVsYXkvU2V2ZXIgc2VlbSB0byBiZSBsYWNrIG9mIA0KPiA+IHNwZWNpZmljIG1lc3NhZ2Vz
LiANCj4gPiAgICAgRm9yIGV4YW1wbGUsIERIQ1B2NCBtZXNzYWdlcywgDQo+ID4gREhDUERJU0NP
VkVSL0RIQ1BPRkZFUi9ESENQUkVRVUVTVC9ESENQQUNLL0RIQ1BOQUsgDQo+ID4gICAgIG1lc3Nh
Z2UsIGhvdyB0byBpbnRlcmFjdCB3aXRoIERIQ1B2NiBtZXNzYWdlcyANCj4gPiBTT0xJQ0lUL0FE
VkVSVElTRS9SRVFVRVNUL0NPTkZJUk0vIA0KPiA+ICAgICBSRU5FVy9SRUxFQVNFL0RFQ0xJTkUg
bWVzc2FnZSAoYXMgYSBvcHRpb24gb2YgREhDUHY2KS4gDQo+ID4gICAgICAgICBCeSB0aGUgd2F5
LCBpbnRlcmFjdGlvbiBwcm9jZXNzIG9mIG1lc3NhZ2VzIG1pZ2h0IGJlIA0KPiA+IGluY2x1ZGVk
IGluIHRoZSBkb2N1bWVudC4gDQo+ID4gDQo+ID4gDQo+ID4gQ2hlZXJzLCANCj4gPiANCj4gPiAN
Cj4gPiBXZWkgDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gPiBkaGN3Z0BpZXRmLm9yZw0KPiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cgDQo+IA0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBtYWlsaW5n
IGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kaGN3Zw0KDQo=
--=_alternative 0025A38348257B9F_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIENvbmejrDwvZm9udD4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgR290IGl0LiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEJ1dCB3aHkgZGVmaW5lDQoyIG5ldyAmcXVvdDttc2ct
dHlwZSZxdW90O3MgaW5zdGVhZCBvZiBleGlzdGluZyBtc2ctdHlwZT8gPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IElmIGRlZmluZSAmcXVv
dDtCT09UUA0KTWVzc2FnZSBPcHRpb24mcXVvdDsgd2l0aCBleGlzdGluZyBESENQdjYgJnF1b3Q7
bXNnLXR5cGUmcXVvdDtzLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPiZuYnNwOyAmbmJzcDsgaXQgd291bGQgZ2V0IElQdjQvSVB2Ng0KYWRkcmVzc2VzIGF0IHRo
ZSBzYW1lIHRpbWUgYW5kIGluIG9uZSBwcm9jZXNzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz
aXplPTI+Q2hlZXJzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
V2VpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Q29uZyBMaXUgJmx0O2dub2N1aWxAZ21haWwuY29tJmd0OyAmbmJzcDsyMDEzLTA3LTA1
DQoxMTo0MDo1ODo8YnI+DQo8YnI+DQomZ3Q7IEhpIFdlaSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGVyZSBhcmUgMiBuZXcgREhDUHY2IG1lc3Nh
Z2VzIChCT09UUkVRVUVTVFY2ICZhbXA7IEJPT1RSRVBMWVY2KQ0KPGJyPg0KJmd0OyBkZWZpbmVk
IGluIHRoZSBkcmFmdC4gVGhlIEJPT1RQIE1lc3NhZ2UgT3B0aW9uICh3aGljaCBjb250YWlucyA8
YnI+DQomZ3Q7IERIQ1B2NCBtZXNzYWdlKSBjYW4gb25seSBiZSBjYXJyaWVkIGluIHRoZSBuZXcg
ZGVmaW5lZCBtZXNzYWdlcy4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
IDxicj4NCiZndDsgQmVzdCBXaXNoZXMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IENvbmc8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Jmd0OyAyMDEzLzcvNSAmbHQ7bWVuZy53ZWkyQHp0ZS5jb20uY24mZ3Q7PC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgRm9yIGV4YW1wbGWjrCBj
bGllbnQgZ2VuZXJhdGVzIERIQ1B2NCBESVNDT1ZFUiBtZXNzYWdlIGFuZCBlbWJlZA0KaXQgPGJy
Pg0KJmd0OyBhcyBhIG9wdGlvbiBpbnRvIDxicj4NCiZndDsgREhDUHY2IFNPTElDSVQgbWVzc2Fn
ZS4gJm5ic3A7SXQgaXMgbmFtZWQgYXMgJnF1b3Q7REhDUHY0IERJU0NPVkVSDQpvdmVyIERIQ1B2
NlNPTElDSVQmcXVvdDsgPGJyPg0KJmd0OyBhbHNvICZxdW90O0RIQ1B2NCBvdmVyIFJFTEFZLUZP
UlcmcXVvdDsvICZuYnNwOyZxdW90O0RIQ1B2NCBPRkZFUg0Kb3ZlciBESENQdjYgQURWRVJUSVNF
JnF1b3Q7PGJyPg0KJmd0OyBhbmQgc28gb24uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3Mu
IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O0Jlcm5pZSBWb2x6ICh2b2x6
KSZxdW90OyAmbHQ7dm9sekBjaXNjby5jb20mZ3Q7ICZuYnNwOzIwMTMtMDctMDUNCjExOjE3OjIy
OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgJmd0OyBIdWg/IFRoZXJlIGlzIG5vIGludGVyYWN0aW9uIC0gdGhlc2UgbmV3IG1lc3Nh
Z2VzIGNvbnRhaW4gbm9ybWFsDQo8YnI+DQomZ3Q7ICZndDsgZGhjcHY0IG1lc3NhZ2VzLjxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLSBCZXJuaWUgKGZyb20gaVBhZCk8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBPbiBKdWwgNCwgMjAxMywgYXQgOTozOCBQTSwgJnF1b3Q7bWVuZy53ZWkyQHp0ZS5jb20u
Y24mcXVvdDsNCiZsdDttZW5nLndlaTJAenRlLmNvbS5jbjxicj4NCiZndDsgJmd0OyAmZ3Q7IHdy
b3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSwgPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBIZXJlIGFyZSBzb21lIGNvbW1l
bnRzIG9uIHRoaXMgZHJhZnQuDQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IFRoZSBiZWhhdmlvdXJzIG9mIENsaWVudC9SZWxheS9TZXZlcg0Kc2VlbSB0byBiZSBs
YWNrIG9mIDxicj4NCiZndDsgJmd0OyBzcGVjaWZpYyBtZXNzYWdlcy4gPGJyPg0KJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGUsIERIQ1B2NCBtZXNzYWdlcywgPGJyPg0KJmd0OyAm
Z3Q7IERIQ1BESVNDT1ZFUi9ESENQT0ZGRVIvREhDUFJFUVVFU1QvREhDUEFDSy9ESENQTkFLIDxi
cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IG1lc3NhZ2UsIGhvdyB0byBpbnRlcmFjdCB3aXRo
IERIQ1B2NiBtZXNzYWdlcyA8YnI+DQomZ3Q7ICZndDsgU09MSUNJVC9BRFZFUlRJU0UvUkVRVUVT
VC9DT05GSVJNLyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBSRU5FVy9SRUxFQVNFL0RF
Q0xJTkUgbWVzc2FnZSAoYXMgYSBvcHRpb24gb2YgREhDUHY2KS4NCjxicj4NCiZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQnkgdGhlIHdheSwgaW50ZXJhY3Rpb24gcHJvY2Vz
cyBvZg0KbWVzc2FnZXMgbWlnaHQgYmUgPGJyPg0KJmd0OyAmZ3Q7IGluY2x1ZGVkIGluIHRoZSBk
b2N1bWVudC4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7IENoZWVycywgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgV2VpIDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQom
Z3Q7ICZndDsgZGhjd2dAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgZGhjd2cgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBkaGN3Z0Bp
ZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
aGN3Zzxicj4NCjwvZm9udD48L3R0Pg0K
--=_alternative 0025A38348257B9F_=--

From gnocuil@gmail.com  Fri Jul  5 00:25: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 2A91121F9BF5 for ; Fri,  5 Jul 2013 00:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level: 
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.225,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcG+1zM4IhjX for ; Fri,  5 Jul 2013 00:25:45 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE321F999C for ; Fri,  5 Jul 2013 00:25:44 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w57so1705556wes.15 for ; Fri, 05 Jul 2013 00:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2vUSOyPQdKNMd5FNMUjhi40/hVhHiMCiWDRmwAL5Eck=; b=lVxaCqKQ6HvGntLTT5XtmsE6QOP/b7PNBF7IA3TvA08anSbIga/VbvltXcWfcsLjIh /46MxX5sDD2MbkkYjvmzEomzO5gXvrY5gnp4d1nwKUF+HybzTHecXRgPZiL1TOBurWkW bc7s8vHslltkmApDliAhpsaiXRKz3bfmjpUHHoyRh0VMne33JNe5WKfetd0f6J9def3d ShL0fme1UJ0VqhbR514LRY1d56x2I8NDx1LYw+objeuxU2UH7WzFO6u3wRfUvwGnyg/q bcCAJePBxftuA0G6D4EvVIpcUg1l+3IknKAs5c8mmTR9nMZ1U6v/VDrpbdS8KV7CBVSy 4bxA==
X-Received: by 10.194.2.13 with SMTP id 13mr5364295wjq.74.1373009144114; Fri, 05 Jul 2013 00:25:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.10.67 with HTTP; Fri, 5 Jul 2013 00:25:24 -0700 (PDT)
In-Reply-To: 
References:  
From: Cong Liu 
Date: Fri, 5 Jul 2013 15:25:24 +0800
Message-ID: 
To: meng.wei2@zte.com.cn
Content-Type: multipart/alternative; boundary=047d7b3a87564ef6e304e0be9ac8
Cc: "dhcwg@ietf.org" , "yong@csnet1.cs.tsinghua.edu.cn" , "Bernie Volz \(volz\)" , "sunqibupt@gmail.com" 
Subject: Re: [dhcwg] [DHC]:Comments on draft-ietf-dhc-dhcpv4-over-dhcpv6
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, 05 Jul 2013 07:25:46 -0000

--047d7b3a87564ef6e304e0be9ac8
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Wei,

Here are some possible reasons:
1. DHCPv6 server and DHCPv4-over-DHCPv6 unified server may be different
servers, so their reply messages can not be merged.
2. IPv6/IPv4 addresses may have different lease time, their renew processes
can not be combined.

Best Wishes,
Cong


2013/7/5 

>
> Hi Cong=A3=AC
>
>       Got it.
>       But why define 2 new "msg-type"s instead of existing msg-type?
>     If define "BOOTP Message Option" with existing DHCPv6 "msg-type"s,
>     it would get IPv4/IPv6 addresses at the same time and in one process.
>
> Cheers,
> Wei
>
>
>
>
>
> Cong Liu   2013-07-05 11:40:58:
>
> > Hi Wei,
> >
> > There are 2 new DHCPv6 messages (BOOTREQUESTV6 & BOOTREPLYV6)
> > defined in the draft. The BOOTP Message Option (which contains
> > DHCPv4 message) can only be carried in the new defined messages.
> >
> > Best Wishes,
> > Cong
> >
>
> > 2013/7/5 
> >
> > For example=A3=AC client generates DHCPv4 DISCOVER message and embed it
> > as a option into
> > DHCPv6 SOLICIT message.  It is named as "DHCPv4 DISCOVER over
> DHCPv6SOLICIT"
> > also "DHCPv4 over RELAY-FORW"/  "DHCPv4 OFFER over DHCPv6 ADVERTISE"
> > and so on.
> >
> > Thanks.
> >
> >
> > "Bernie Volz (volz)"   2013-07-05 11:17:22:
> >
> >
> > > Huh? There is no interaction - these new messages contain normal
> > > dhcpv4 messages.
> > >
> > > - Bernie (from iPad)
> >
> > >
> > > On Jul 4, 2013, at 9:38 PM, "meng.wei2@zte.com.cn" <
> meng.wei2@zte.com.cn
> > > > wrote:
> >
> > >
> > > Hi,
> > >         Here are some comments on this draft.
> > >         The behaviours of Client/Relay/Sever seem to be lack of
> > > specific messages.
> > >     For example, DHCPv4 messages,
> > > DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK
> > >     message, how to interact with DHCPv6 messages
> > > SOLICIT/ADVERTISE/REQUEST/CONFIRM/
> > >     RENEW/RELEASE/DECLINE message (as a option of DHCPv6).
> > >         By the way, interaction process of messages might be
> > > included in the document.
> > >
> > >
> > > Cheers,
> > >
> > >
> > > Wei
> > > _______________________________________________
> > > 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
>

--047d7b3a87564ef6e304e0be9ac8
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable


Hi Wei,

Here are some possible reasons:
=

1. DHCPv6 server and DHCPv4-over-DHCPv6 unified server may be differen=
t servers, so their reply messages can not be merged.
2. IPv6/IPv=
4 addresses may have different lease time, their renew processes can not be=
 combined.




Best Wishes,
Cong



2013/7/5  <meng.wei2@zte.com.cn=
>




Hi Cong=A3=AC



      Got it.  

      But why define
2 new "msg-type"s instead of existing msg-type? 

    If define "BOOTP
Message Option" with existing DHCPv6 "msg-type"s, 

    it would get IPv4/IPv6
addresses at the same time and in one process.



Cheers,

Wei











Cong Liu <gnocuil@gmail.com>  2013-07-05
11:40:58:



> Hi Wei,

> 

> There are 2 new DHCPv6 messages (BOOTREQUESTV6 & BOOTREPLYV6)


> defined in the draft. The BOOTP Message Option (which contains 

> DHCPv4 message) can only be carried in the new defined messages. 

> 

> Best Wishes,

> Cong

> 



> 2013/7/5 <meng.wei2@zte.com.cn>

> 

> For example=A3=AC client generates DHCPv4 DISCOVER message and embed
it 

> as a option into 

> DHCPv6 SOLICIT message.  It is named as "DHCPv4 DISCOVER
over DHCPv6SOLICIT" 

> also "DHCPv4 over RELAY-FORW"/  "DHCPv4 OFFER
over DHCPv6 ADVERTISE"

> and so on. 

> 

> Thanks. 

> 

> 

> "Bernie Volz (volz)" <volz@cisco.com>  2013-07-05
11:17:22:

> 

> 

> > Huh? There is no interaction - these new messages contain normal


> > dhcpv4 messages.

> > 

> > - Bernie (from iPad)

> 

> > 

> > On Jul 4, 2013, at 9:38 PM, "meng.wei2@zte.com.cn"
<meng.wei2@zte=
.com.cn

> > > wrote:

> 

> > 

> > Hi, 

> >         Here are some comments on this draft.


> >         The behaviours of Client/Relay/Sever
seem to be lack of 

> > specific messages. 

> >     For example, DHCPv4 messages, 

> > DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK/DHCPNAK 

> >     message, how to interact with DHCPv6 messages 

> > SOLICIT/ADVERTISE/REQUEST/CONFIRM/ 

> >     RENEW/RELEASE/DECLINE message (as a option of DHCPv=
6).


> >         By the way, interaction process of
messages might be 

> > included in the document. 

> >   

> > 

> > Cheers, 

> > 

> > 

> > Wei 

> > _______________________________________________

> > dhcwg mailing list

> > dhcwg@ietf.or=
g

> > https://www.ietf.org/mailman/listinfo/dhcwg 

> 

> _______________________________________________

> dhcwg mailing list

> dhcwg@ietf.org=


> https://www.ietf.org/mailman/listinfo/dhcwg






--047d7b3a87564ef6e304e0be9ac8--

From mglt.ietf@gmail.com  Fri Jul  5 03:06: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 2880F11E8287 for ; Fri,  5 Jul 2013 03:06:15 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FMUanipVjkf for ; Fri,  5 Jul 2013 03:06:14 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id EAAE811E8286 for ; Fri,  5 Jul 2013 03:06:13 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id a12so1795718wgh.28 for ; Fri, 05 Jul 2013 03:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5NOMg6RHw4AKwlpKX+BXRHUUAq8BDGRTpw3qAGORctQ=; b=S96Lw15Hn0WYcE3lQ0Mz/OCDcFg3kuskQZWggpvelLCNl0I4dGi5W5/QaWfhCY+e7/ GmgldVyW6T48eBnv70681EbGqecYtnGdIhfHry7j+sej+eVWVvLf02I9L53Jn/R5f2r6 O/AOTSmWHRbu+ySA+TArEMzNJ7KbpfYGN392XBQPQmtQPFC1gNH2kvDHmDuoSnOwy7CL yuEQr7xK7s6AiTcH9CBkaTfPXTwU+m+PmwdGspy0NmPDg0Ccvr0Z4vjYcoc2eFfCCygH XipVTg7gurBmGNb1ZB+G/scJRxhYOOFRE7Plj1lvx1ZVXZ6Gy2L6AmBrW9oMiwGCykiy 1TFg==
MIME-Version: 1.0
X-Received: by 10.194.110.6 with SMTP id hw6mr5801233wjb.3.1373018773078; Fri, 05 Jul 2013 03:06:13 -0700 (PDT)
Received: by 10.194.163.134 with HTTP; Fri, 5 Jul 2013 03:06:13 -0700 (PDT)
In-Reply-To: <20130705093503.1552.95416.idtracker@ietfa.amsl.com>
References: <20130705093503.1552.95416.idtracker@ietfa.amsl.com>
Date: Fri, 5 Jul 2013 12:06:13 +0200
Message-ID: 
From: Daniel Migault 
To: dhcwg@ietf.org
Content-Type: multipart/alternative; boundary=047d7bf1985e3d492d04e0c0d85e
Cc: Ralf Weber , Wouter Cloetens , Chris Griffiths 
Subject: [dhcwg] Fwd: New Version Notification for draft-mglt-dhc-public-authoritative-server-option-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, 05 Jul 2013 10:06:15 -0000

--047d7bf1985e3d492d04e0c0d85e
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Please find the 00 version of our draft for configuring Home Network Naming
Architecture with DHCP.
http://www.ietf.org/internet-drafts/draft-mglt-dhc-public-authoritative-server-option-00.txt

Feel free to make comments!

Best Regards,

Daniel

---------- Forwarded message ----------
From: 
Date: Fri, Jul 5, 2013 at 11:35 AM
Subject: New Version Notification for draft-mglt-dhc
-public-authoritative-server-option-00.txt
To: Wouter Cloetens , Chris Griffiths <
cgriffiths@dyn.com>, Daniel Migault , Ralf Weber <
ralf.weber@nominum.com>



A new version of I-D, draft-mglt-dhc-public-authoritative-server-option-00.
txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename:        draft-mglt-dhc-public-authoritative-server-option
Revision:        00
Title:           DHCP DNS Public Authoritative Server Option
Creation date:   2013-07-05
Group:           Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-mglt-dhc-public-authoritative-server-option-00.txt
Status:
http://datatracker.ietf.org/doc/draft-mglt-dhc-public-authoritative-server-option
Htmlized:
http://tools.ietf.org/html/draft-mglt-dhc-public-authoritative-server-option-00


Abstract:
   The home network naming architecture as described in
   [I-D.mglt-homenet-front-end-naming-delegation] requires a complex
   naming configuration on the CPE.  This configuration MAY not be
   handled easily by the average end user.  Furthermore, such
   misconfiguration MAY result in making home network unreachable.

   This document proposes a DHCP option that provides the CPE all
   necessary parameters to set up the home network naming architecture.

   First, this DHCP option provides automatic configuration and avoids
   most end users' misconfigurations.  Most average end users may not
   require specific configuration, and their ISP default configuration
   MAY fully address their needs.  In that case, the naming homenet
   architecture configuration will be completely transparent to the end
   users.  Then, saving naming configuration outside the CPE, makes it
   resilient to change of CPE or CPE upgrades.  Such configuration may
   also be configured by the end user, via the customer area of their
   ISP.




The IETF Secretariat




-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--047d7bf1985e3d492d04e0c0d85e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,=A0

Please find the 00 version of ou=
r draft for configuring Home Network Naming Architecture with DHCP.
http://www.ietf.org/inte=
rnet-drafts/draft-mglt-dhc-public-authoritative-server-option-00.txt


Feel free to make comments!

<=
div>Best Regards,=A0

Daniel

---------- Forwarded message ----------=


From:  <internet-drafts@ietf.org<=
/a>>

Date: Fri, Jul 5, 2013 at 11:35 AM
Subject: New Version Notification for=
 draft-mglt-dhc-public-authoritative-server-option-00.txt

To: Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths &l=
t;cgriffiths@dyn.co=
m>, Daniel Migault <mglt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>






A new version of I-D, draft-mglt-dhc-public-authoritative-server-opti=
on-00.txt


has been successfully submi=
tted by Daniel Migault and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-mglt-dhc-public-authoritative-server-o=
ption


Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 DHCP DNS Public Authoritative Server Option

Creation date: =A0 2013-07-05

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 14

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mglt-dhc-public-authoritative-s=
erver-option-00.txt



Status: =A0 =A0 =A0 =A0 =A0http://data=
tracker.ietf.org/doc/draft-mglt-dhc-public-authoritative-server-option<=
br>
Html=
ized: =A0 =A0 =A0 =A0http://tools=
.ietf.org/html/draft-mglt-dhc-public-authoritative-server-option-00






Abstract:

=A0 =A0The home network naming architecture as described in

=A0 =A0[I-D.mglt-homenet-front-end-naming-delegatio=
n] requires a complex


=A0 =A0naming configuration=
 on the CPE. =A0This configuration MAY not be

=A0 =A0handled easily by th=
e average end user. =A0Furthermore, such

=A0 =A0misconfiguration MAY=
 result in making home network unreachable.



=A0 =A0This document proposes a DHCP option that provides the CPE all

=A0 =A0necessary parameters=
 to set up the home network naming architecture.



=A0 =A0First, this DHCP option provides automatic configuration and avoids<=
br>
=A0 =A0most end users' =
misc=
onfigurations. =A0Most average end users may not

=A0 =A0require specific con=
figuration, and their ISP default configuration

=A0 =A0MAY fully address their needs. =A0In that case, the naming homenet

=A0 =A0architecture configu=
ration will be completely transparent to the end

=A0 =A0users. =A0Then, savi=
ng naming configuration outside the CPE, makes it

=A0 =A0resilient to change =
of CPE or CPE upgrades. =A0Such configuration may

=A0 =A0also be configured b=
y the end user, via the customer area of their

=A0 =A0ISP.









The IETF Secretariat







-- 
Daniel Migault
Orange =
Labs -- Security
+33 6 70 72 69 58



--047d7bf1985e3d492d04e0c0d85e--

From volz@cisco.com  Fri Jul  5 11:56:44 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 E8BED21F9FF9 for ; Fri,  5 Jul 2013 11:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-j8x2Z6s3yw for ; Fri,  5 Jul 2013 11:56:40 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 90E2921F9FF8 for ; Fri,  5 Jul 2013 11:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1373050600; x=1374260200; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=lajnfnyATBafK7iv/wXvmPJ2+AbMpwobKIZhtzWV5Qk=; b=F19ckqLNb5kGE/1IGjeqNeOSswiPgy6EmMRVu6G+FwpxVXDOo33iz+vC O2dxiwgiw44BuZ8TRZhdDwBL5RdC6EJOTCoUuNoKnbzO7uGKjl1cqdj6u aN1T73mDoPwVkGCWqU1cGDu/7pjBnDNjPBDRAuYUfIqOEmKADIlHJoFlI o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAOEV11GtJXG+/2dsb2JhbABagwkyScBHgQEWdIIjAQEBBAEBATc0CwwGARkEAQEBChQJLgsUCQkBBA4FCIgHDLkdjzoxDYJ+aQOYcpAcgViBOYIo
X-IronPort-AV: E=Sophos;i="4.87,1003,1363132800"; d="scan'208";a="231393612"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jul 2013 18:56:39 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r65Iuch6012251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 18:56:38 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 13:56:38 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: Remidner - RE: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: Ac55sVa4u2I4f6HkSTKe6J0B99Fubg==
Date: Fri, 5 Jul 2013 18:56:37 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185D5189@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.86.255.130]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 05 Jul 2013 18:56:45 -0000

Hi:

Just a reminder about this WGLC. While it technically should have ended yes=
terday, Tomek and I will review on Monday to determine whether we have roug=
h consensus for this to move forward. So, there is still time for you to ge=
t your comments in.

While we've had some responses, more would be useful to help us gauge rough=
 consensus.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T=
omek Mrugalski
Sent: Thursday, June 20, 2013 12:23 PM
To: dhcwg@ietf.org WG
Cc: Ralph Droms; Ted Lemon
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond=
 by July 4

On 20.06.2013 17:11, Ralph Droms wrote:
> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:
>> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
>> last-call it now?
>=20
> OK with me.
My understanding is that under normal circumstances chairs cannot just anno=
unce WGLC on their own. They can do so if authors or editors state the the =
draft is ready and chairs concur with that opinion. Anyway, here it goes:

Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
feels it's ready for work group last call. Please review this draft and ind=
icate whether or not you feel it is ready to be published.

This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control=
 SOLICIT and INFORMATION-REQUEST message retransmissions and define a mecha=
nism for server to override client's default values. There is a document in=
 v6ops about basic requirements for IPv6 CE routers that depends on this wo=
rk.

At the time of this writing, there is no IPR reported against this draft.

Bernie and I will evaluate consensus after 2013-07-04.

Thanks,
Bernie & Tomek
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

From Dmitry.Anipko@microsoft.com  Fri Jul  5 16: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 BBF4E21F9FDD for ; Fri,  5 Jul 2013 16:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.133
X-Spam-Level: 
X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu4NFP29KJ5t for ; Fri,  5 Jul 2013 16:18:06 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 4E00C21F9B60 for ; Fri,  5 Jul 2013 16:18:06 -0700 (PDT)
Received: from BN1AFFO11FD001.protection.gbl (10.58.52.201) by BN1AFFO11HUB045.protection.gbl (10.58.52.156) with Microsoft SMTP Server (TLS) id 15.0.717.3; Fri, 5 Jul 2013 23:18:04 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD001.mail.protection.outlook.com (10.58.52.61) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Fri, 5 Jul 2013 23:18:04 +0000
Received: from CO9EHSOBE009.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Fri, 5 Jul 2013 23:17:54 +0000
Received: from mail196-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.22; Fri, 5 Jul 2013 23:14:25 +0000
Received: from mail196-co9 (localhost [127.0.0.1])	by mail196-co9-R.bigfish.com (Postfix) with ESMTP id 678C87C0244	for ; Fri,  5 Jul 2013 23:14:25 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -26
X-BigFish: PS-26(zzbb2dI14dfI98dI9371I146fI542I1432I4015I168aJzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h)
Received-SPF: softfail (mail196-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Dmitry.Anipko@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(57704003)(13464003)(53434003)(24454002)(51704005)(164054003)(199002)(189002)(52314003)(377454003)(479174003)(47976001)(65816001)(79102001)(74876001)(50986001)(47736001)(4396001)(33646001)(81542001)(74706001)(63696002)(76482001)(15202345003)(49866001)(81342001)(76786001)(80022001)(56776001)(69226001)(54356001)(83072001)(77096001)(53806001)(74366001)(76576001)(47446002)(46102001)(16406001)(77982001)(56816003)(74502001)(51856001)(54316002)(74316001)(31966008)(74662001)(59766001)(76796001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB077; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:d8:f04b:9588:a3b2:5bec:35ca; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail196-co9 (localhost.localdomain [127.0.0.1]) by mail196-co9 (MessageSwitch) id 1373066063106094_28033; Fri,  5 Jul 2013 23:14:23 +0000 (UTC)
Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.244])	by mail196-co9.bigfish.com (Postfix) with ESMTP id 0C58890004A; Fri,  5 Jul 2013 23:14:23 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Jul 2013 23:14:14 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.324.0; Fri, 5 Jul 2013 23:14:12 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.731.11; Fri, 5 Jul 2013 23:14:10 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.77]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.77]) with mapi id 15.00.0731.000; Fri, 5 Jul 2013 23:14:10 +0000
From: Dmitry Anipko 
To: "Bernie Volz (volz)" , "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: Ac55sVa4u2I4f6HkSTKe6J0B99FubgAIzfTv
Date: Fri, 5 Jul 2013 23:14:10 +0000
Message-ID: <252fd7a5b11c4bb4ad0b3ead61821c8d@SN2PR03MB077.namprd03.prod.outlook.com>
References: <489D13FBFA9B3E41812EA89F188F018E185D5189@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185D5189@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:d8:f04b:9588:a3b2:5bec:35ca]
x-forefront-prvs: 0898A6E028
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN2PR03MB077.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054003)(57704003)(199002)(189002)(13464003)(52314003)(51704005)(24454002)(377454003)(479174003)(53434003)(50986001)(47736001)(80022001)(16676001)(59766001)(79102001)(4396001)(74316001)(49866001)(47976001)(54316002)(33646001)(74876001)(51856001)(46406003)(74706001)(53806001)(54356001)(56776001)(81342001)(15202345003)(50466002)(76786001)(63696002)(69226001)(74502001)(74662001)(23726002)(76796001)(76576001)(74366001)(6806003)(47446002)(47776003)(20776003)(31966008)(46102001)(77982001)(76482001)(65816001)(83072001)(77096001)(56816003)(81542001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB045; H:TK5EX14HUBC107.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0898A6E028
Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 05 Jul 2013 23:18:11 -0000

I've read the document and support moving it forward - IMO, it will help to=
 reduce useless load on servers as well as save energy on resource constrai=
ned clients.=0A=
=0A=
One comment on the security section: do I understand correctly that if the =
malicious DHCP server sends an arbitrarily high value for either of the opt=
ions, while the non-malicious DHCP server was temporarily down, then the cl=
ient may not recover for a very long time? If such vector exists, would it =
be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is a=
llowed to send to the client? (e.g. to 1h, or several hours or whatever)=0A=
=0A=
-Dmitry=0A=
________________________________________=0A=
From: dhcwg-bounces@ietf.org  on behalf of Bernie V=
olz (volz) =0A=
Sent: Friday, July 05, 2013 11:56 AM=0A=
To: dhcwg@ietf.org=0A=
Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-upda=
te-01 - respond by July 4=0A=
=0A=
Hi:=0A=
=0A=
Just a reminder about this WGLC. While it technically should have ended yes=
terday, Tomek and I will review on Monday to determine whether we have roug=
h consensus for this to move forward. So, there is still time for you to ge=
t your comments in.=0A=
=0A=
While we've had some responses, more would be useful to help us gauge rough=
 consensus.=0A=
=0A=
- Bernie=0A=
=0A=
-----Original Message-----=0A=
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T=
omek Mrugalski=0A=
Sent: Thursday, June 20, 2013 12:23 PM=0A=
To: dhcwg@ietf.org WG=0A=
Cc: Ralph Droms; Ted Lemon=0A=
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond=
 by July 4=0A=
=0A=
On 20.06.2013 17:11, Ralph Droms wrote:=0A=
> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:=0A=
>> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just=0A=
>> last-call it now?=0A=
>=0A=
> OK with me.=0A=
My understanding is that under normal circumstances chairs cannot just anno=
unce WGLC on their own. They can do so if authors or editors state the the =
draft is ready and chairs concur with that opinion. Anyway, here it goes:=
=0A=
=0A=
Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01=0A=
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)=0A=
feels it's ready for work group last call. Please review this draft and ind=
icate whether or not you feel it is ready to be published.=0A=
=0A=
This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control=
 SOLICIT and INFORMATION-REQUEST message retransmissions and define a mecha=
nism for server to override client's default values. There is a document in=
 v6ops about basic requirements for IPv6 CE routers that depends on this wo=
rk.=0A=
=0A=
At the time of this writing, there is no IPR reported against this draft.=
=0A=
=0A=
Bernie and I will evaluate consensus after 2013-07-04.=0A=
=0A=
Thanks,=0A=
Bernie & Tomek=0A=
_______________________________________________=0A=
dhcwg mailing list=0A=
dhcwg@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dhcwg=0A=
_______________________________________________=0A=
dhcwg mailing list=0A=
dhcwg@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dhcwg=0A=
=0A=
=0A=


From stenc@s-carlsen.dk  Fri Jul  5 16:30:26 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 D351A21F9D65 for ; Fri,  5 Jul 2013 16:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfJjK8LxoQ0v for ; Fri,  5 Jul 2013 16:30:22 -0700 (PDT)
Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02621F9D67 for ; Fri,  5 Jul 2013 16:30:22 -0700 (PDT)
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 6B396521F for ; Sat,  6 Jul 2013 01:30:17 +0200 (CEST)
Message-ID: <51D75708.4020901@s-carlsen.dk>
Date: Sat, 06 Jul 2013 01:30:16 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <489D13FBFA9B3E41812EA89F188F018E185D5189@xmb-rcd-x04.cisco.com> <252fd7a5b11c4bb4ad0b3ead61821c8d@SN2PR03MB077.namprd03.prod.outlook.com>
In-Reply-To: <252fd7a5b11c4bb4ad0b3ead61821c8d@SN2PR03MB077.namprd03.prod.outlook.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------010205060907090508090704"
Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 05 Jul 2013 23:30:26 -0000

This is a multi-part message in MIME format.
--------------010205060907090508090704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

If you look at malicious servers, does it matter what the server is
allowed to do? It might be better to state what the client may accept?


On 06/07/13 1:14, Dmitry Anipko wrote:
> I've read the document and support moving it forward - IMO, it will help to reduce useless load on servers as well as save energy on resource constrained clients.
>
> One comment on the security section: do I understand correctly that if the malicious DHCP server sends an arbitrarily high value for either of the options, while the non-malicious DHCP server was temporarily down, then the client may not recover for a very long time? If such vector exists, would it be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is allowed to send to the client? (e.g. to 1h, or several hours or whatever)
>
> -Dmitry
> ________________________________________
> From: dhcwg-bounces@ietf.org  on behalf of Bernie Volz (volz) 
> Sent: Friday, July 05, 2013 11:56 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
>
> Hi:
>
> Just a reminder about this WGLC. While it technically should have ended yesterday, Tomek and I will review on Monday to determine whether we have rough consensus for this to move forward. So, there is still time for you to get your comments in.
>
> While we've had some responses, more would be useful to help us gauge rough consensus.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
> Sent: Thursday, June 20, 2013 12:23 PM
> To: dhcwg@ietf.org WG
> Cc: Ralph Droms; Ted Lemon
> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
>
> On 20.06.2013 17:11, Ralph Droms wrote:
>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:
>>> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
>>> last-call it now?
>> OK with me.
> My understanding is that under normal circumstances chairs cannot just announce WGLC on their own. They can do so if authors or editors state the the draft is ready and chairs concur with that opinion. Anyway, here it goes:
>
> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
> feels it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.
>
> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control SOLICIT and INFORMATION-REQUEST message retransmissions and define a mechanism for server to override client's default values. There is a document in v6ops about basic requirements for IPv6 CE routers that depends on this work.
>
> At the time of this writing, there is no IPR reported against this draft.
>
> Bernie and I will evaluate consensus after 2013-07-04.
>
> Thanks,
> Bernie & Tomek
> _______________________________________________
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


--------------010205060907090508090704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    If you look at malicious servers, does it matter what the server is
    allowed to do? It might be better to state what the client may
    accept?

    

    

    
On 06/07/13 1:14, Dmitry Anipko wrote:

    

    

      
I've read the document and support moving it forward - IMO, it will help to reduce useless load on servers as well as save energy on resource constrained clients.

One comment on the security section: do I understand correctly that if the malicious DHCP server sends an arbitrarily high value for either of the options, while the non-malicious DHCP server was temporarily down, then the client may not recover for a very long time? If such vector exists, would it be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is allowed to send to the client? (e.g. to 1h, or several hours or whatever)

-Dmitry
________________________________________
From: dhcwg-bounces@ietf.org <dhcwg-bounces@ietf.org> on behalf of Bernie Volz (volz) <volz@cisco.com>
Sent: Friday, July 05, 2013 11:56 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

Hi:

Just a reminder about this WGLC. While it technically should have ended yesterday, Tomek and I will review on Monday to determine whether we have rough consensus for this to move forward. So, there is still time for you to get your comments in.

While we've had some responses, more would be useful to help us gauge rough consensus.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Thursday, June 20, 2013 12:23 PM
To: dhcwg@ietf.org WG
Cc: Ralph Droms; Ted Lemon
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

On 20.06.2013 17:11, Ralph Droms wrote:


      

        
On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:


        

          
Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
last-call it now?


        

        
OK with me.


      

      
My understanding is that under normal circumstances chairs cannot just announce WGLC on their own. They can do so if authors or editors state the the draft is ready and chairs concur with that opinion. Anyway, here it goes:

Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
feels it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.

This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control SOLICIT and INFORMATION-REQUEST message retransmissions and define a mechanism for server to override client's default values. There is a document in v6ops about basic requirements for IPv6 CE routers that depends on this work.

At the time of this writing, there is no IPR reported against this draft.

Bernie and I will evaluate consensus after 2013-07-04.

Thanks,
Bernie & Tomek
_______________________________________________
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


    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


  


--------------010205060907090508090704--

From Dmitry.Anipko@microsoft.com  Fri Jul  5 16:33:06 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 D40CB21F9E58 for ; Fri,  5 Jul 2013 16:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.133
X-Spam-Level: 
X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[AWL=-0.001,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyeP1yfoby2F for ; Fri,  5 Jul 2013 16:33:01 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 61B4921F9D65 for ; Fri,  5 Jul 2013 16:33:01 -0700 (PDT)
Received: from BL2FFO11FD006.protection.gbl (10.173.161.204) by BL2FFO11HUB025.protection.gbl (10.173.161.49) with Microsoft SMTP Server (TLS) id 15.0.717.3; Fri, 5 Jul 2013 23:32:55 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Fri, 5 Jul 2013 23:32:55 +0000
Received: from CO9EHSOBE034.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Fri, 5 Jul 2013 23:32:51 +0000
Received: from mail156-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.22; Fri, 5 Jul 2013 23:32:51 +0000
Received: from mail156-co9 (localhost [127.0.0.1])	by mail156-co9-R.bigfish.com (Postfix) with ESMTP id 6939AE0093	for ; Fri,  5 Jul 2013 23:32:51 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -25
X-BigFish: PS-25(zzbb2dI14dfI98dI9371Ic85fh146fI542I4015I168aJzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h)
Received-SPF: softfail (mail156-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Dmitry.Anipko@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(377454003)(479174003)(24454002)(53434003)(13464003)(52314003)(57704003)(51856001)(76576001)(4396001)(69226001)(53806001)(77096001)(80022001)(54356001)(54316002)(77982001)(56776001)(74366001)(74316001)(16406001)(76786001)(65816001)(16236675002)(46102001)(83072001)(47446002)(56816003)(76796001)(74502001)(63696002)(74706001)(79102001)(47976001)(49866001)(47736001)(15202345003)(50986001)(74876001)(76482001)(31966008)(59766001)(81542001)(33646001)(74662001)(81342001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:d8:f04b:9588:a3b2:5bec:35ca; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail156-co9 (localhost.localdomain [127.0.0.1]) by mail156-co9 (MessageSwitch) id 1373067168539262_12366; Fri,  5 Jul 2013 23:32:48 +0000 (UTC)
Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.245])	by mail156-co9.bigfish.com (Postfix) with ESMTP id 7E3A260274; Fri,  5 Jul 2013 23:32:48 +0000 (UTC)
Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Jul 2013 23:32:48 +0000
Received: from SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.324.0; Fri, 5 Jul 2013 23:32:46 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.731.11; Fri, 5 Jul 2013 23:32:44 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.77]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.77]) with mapi id 15.00.0731.000; Fri, 5 Jul 2013 23:32:44 +0000
From: Dmitry Anipko 
To: Sten Carlsen , "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: Ac55sVa4u2I4f6HkSTKe6J0B99FubgAIzfTvAADDCAAAAA911g==
Date: Fri, 5 Jul 2013 23:32:43 +0000
Message-ID: <5d8123dac718421a9e0a2e1f597b4efc@SN2PR03MB077.namprd03.prod.outlook.com>
References: <489D13FBFA9B3E41812EA89F188F018E185D5189@xmb-rcd-x04.cisco.com> <252fd7a5b11c4bb4ad0b3ead61821c8d@SN2PR03MB077.namprd03.prod.outlook.com>, <51D75708.4020901@s-carlsen.dk>
In-Reply-To: <51D75708.4020901@s-carlsen.dk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:d8:f04b:9588:a3b2:5bec:35ca]
x-forefront-prvs: 0898A6E028
Content-Type: multipart/alternative; boundary="_000_5d8123dac718421a9e0a2e1f597b4efcSN2PR03MB077namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN2PR03MB078.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%S-CARLSEN.DK$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(164054003)(57704003)(199002)(189002)(52314003)(53434003)(24454002)(479174003)(377454003)(81542001)(76786001)(74662001)(44976004)(71186001)(65816001)(76576001)(50986001)(47976001)(74706001)(33646001)(16676001)(74316001)(47736001)(16236675002)(80022001)(4396001)(6806003)(15202345003)(79102001)(54316002)(49866001)(81342001)(53806001)(56816003)(47446002)(76482001)(76796001)(83072001)(512954002)(46102001)(51856001)(63696002)(74876001)(59766001)(56776001)(74366001)(77982001)(69226001)(54356001)(31966008)(20776003)(74502001)(77096001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB025; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0898A6E028
Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 05 Jul 2013 23:33:06 -0000

--_000_5d8123dac718421a9e0a2e1f597b4efcSN2PR03MB077namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>If you look at malicious servers, does it matter what the server is allow=
ed to do? It might be better to state what the client may accept?

Yes, that's what I meant with "allowed" - that the client would have to val=
idate against that limit, and either ignore the invalid message, or cap the=
 value to the max allowed.
________________________________
From: dhcwg-bounces@ietf.org  on behalf of Sten Car=
lsen 
Sent: Friday, July 05, 2013 4:30 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-=
update-01 - respond by July 4

If you look at malicious servers, does it matter what the server is allowed=
 to do? It might be better to state what the client may accept?


On 06/07/13 1:14, Dmitry Anipko wrote:

I've read the document and support moving it forward - IMO, it will help to=
 reduce useless load on servers as well as save energy on resource constrai=
ned clients.

One comment on the security section: do I understand correctly that if the =
malicious DHCP server sends an arbitrarily high value for either of the opt=
ions, while the non-malicious DHCP server was temporarily down, then the cl=
ient may not recover for a very long time? If such vector exists, would it =
be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is a=
llowed to send to the client? (e.g. to 1h, or several hours or whatever)

-Dmitry
________________________________________
From: dhcwg-bounces@ietf.org  on behalf of Bernie Volz (volz) 
Sent: Friday, July 05, 2013 11:56 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-upda=
te-01 - respond by July 4

Hi:

Just a reminder about this WGLC. While it technically should have ended yes=
terday, Tomek and I will review on Monday to determine whether we have roug=
h consensus for this to move forward. So, there is still time for you to ge=
t your comments in.

While we've had some responses, more would be useful to help us gauge rough=
 consensus.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-b=
ounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Thursday, June 20, 2013 12:23 PM
To: dhcwg@ietf.org WG
Cc: Ralph Droms; Ted Lemon
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond=
 by July 4

On 20.06.2013 17:11, Ralph Droms wrote:


On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:


Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
last-call it now?


OK with me.


My understanding is that under normal circumstances chairs cannot just anno=
unce WGLC on their own. They can do so if authors or editors state the the =
draft is ready and chairs concur with that opinion. Anyway, here it goes:

Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
feels it's ready for work group last call. Please review this draft and ind=
icate whether or not you feel it is ready to be published.

This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control=
 SOLICIT and INFORMATION-REQUEST message retransmissions and define a mecha=
nism for server to override client's default values. There is a document in=
 v6ops about basic requirements for IPv6 CE routers that depends on this wo=
rk.

At the time of this writing, there is no IPR reported against this draft.

Bernie and I will evaluate consensus after 2013-07-04.

Thanks,
Bernie & Tomek
_______________________________________________
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



--
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


--_000_5d8123dac718421a9e0a2e1f597b4efcSN2PR03MB077namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









>>If you look at malicious se=
rvers, does it matter what the server is allowed to do? It might be better =
to state what the client may accept?






Yes, that's what I meant with "allowed&qu=
ot; - that the client would have to validate against that limit, and either=
 ignore the invalid message, or cap the value to the max allowed.







From: dhcwg-bounces@ietf.or=
g <dhcwg-bounces@ietf.org> on behalf of Sten Carlsen <stenc@s-carl=
sen.dk>

Sent: Friday, July 05, 2013 4:30 PM

To: dhcwg@ietf.org

Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-so=
lmaxrt-update-01 - respond by July 4

 




If you look at malicious servers, does it matter what the server is al=
lowed to do? It might be better to state what the client may accept?






On 06/07/13 1:14, Dmitry Anipko wrote:






I've read the document and support moving it forward - IMO, it will he=
lp to reduce useless load on servers as well as save energy on resource con=
strained clients.=0A=
=0A=
One comment on the security section: do I understand correctly that if the =
malicious DHCP server sends an arbitrarily high value for either of the opt=
ions, while the non-malicious DHCP server was temporarily down, then the cl=
ient may not recover for a very long time? If such vector exists, would it =
be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is a=
llowed to send to the client? (e.g. to 1h, or several hours or whatever)=0A=
=0A=
-Dmitry=0A=
________________________________________=0A=
From: dhcwg-bounces@ietf.org <dhcwg-bounces@ietf.org> on be=
half of Bernie Volz (volz) <volz@cisco.com>=0A=
Sent: Friday, July 05, 2013 11:56 AM=0A=
To: dh=
cwg@ietf.org=0A=
Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-upda=
te-01 - respond by July 4=0A=
=0A=
Hi:=0A=
=0A=
Just a reminder about this WGLC. While it technically should have ended yes=
terday, Tomek and I will review on Monday to determine whether we have roug=
h consensus for this to move forward. So, there is still time for you to ge=
t your comments in.=0A=
=0A=
While we've had some responses, more would be useful to help us gauge rough=
 consensus.=0A=
=0A=
- Bernie=0A=
=0A=
-----Original Message-----=0A=
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Be=
half Of Tomek Mrugalski=0A=
Sent: Thursday, June 20, 2013 12:23 PM=0A=
To: dh=
cwg@ietf.org WG=0A=
Cc: Ralph Droms; Ted Lemon=0A=
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond=
 by July 4=0A=
=0A=
On 20.06.2013 17:11, Ralph Droms wrote:=0A=





On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:=0A=





Do we need a SOL_MAX_RT presentation in Berlin?   Why not just=0A=
last-call it now?=0A=





OK with me.=0A=





My understanding is that under normal circumstances chairs cannot just=
 announce WGLC on their own. They can do so if authors or editors state the=
 the draft is ready and chairs concur with that opinion. Anyway, here it go=
es:=0A=
=0A=
Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01=0A=
(http://tools.ietf.org/html/draft-ietf=
-dhc-dhcpv6-solmaxrt-update-01)=0A=
feels it's ready for work group last call. Please review this draft and ind=
icate whether or not you feel it is ready to be published.=0A=
=0A=
This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control=
 SOLICIT and INFORMATION-REQUEST message retransmissions and define a mecha=
nism for server to override client's default values. There is a document in=
 v6ops about basic requirements for IPv6 CE routers that depends on this wo=
rk.=0A=
=0A=
At the time of this writing, there is no IPR reported against this draft.=
=0A=
=0A=
Bernie and I will evaluate consensus after 2013-07-04.=0A=
=0A=
Thanks,=0A=
Bernie & Tomek=0A=
_______________________________________________=0A=
dhcwg mailing list=0A=
dhcwg@=
ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dhcwg=0A=
_______________________________________________=0A=
dhcwg mailing list=0A=
dhcwg@=
ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dhcwg=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
dhcwg mailing list=0A=
dhcwg@=
ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dhcwg=0A=







-- =0A=
Best regards=0A=
=0A=
Sten Carlsen=0A=
=0A=
No improvements come from shouting:=0A=
       "MALE BOVINE MANURE!!!"=0A=













--_000_5d8123dac718421a9e0a2e1f597b4efcSN2PR03MB077namprd03pro_--

From stenc@s-carlsen.dk  Fri Jul  5 17:09: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 C61A921F873C for ; Fri,  5 Jul 2013 17:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.229
X-Spam-Level: 
X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ndbbJLKTy2g for ; Fri,  5 Jul 2013 17:09:35 -0700 (PDT)
Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD521F85B3 for ; Fri,  5 Jul 2013 17:09:34 -0700 (PDT)
Received: from silver3airport.s-carlsen.dk (silver3AirPort.s-carlsen.dk [192.168.16.117]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 4706B51CD; Sat,  6 Jul 2013 02:09:29 +0200 (CEST)
Message-ID: <51D76039.6070902@s-carlsen.dk>
Date: Sat, 06 Jul 2013 02:09:29 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Dmitry Anipko 
References: <489D13FBFA9B3E41812EA89F188F018E185D5189@xmb-rcd-x04.cisco.com> <252fd7a5b11c4bb4ad0b3ead61821c8d@SN2PR03MB077.namprd03.prod.outlook.com>, <51D75708.4020901@s-carlsen.dk> <5d8123dac718421a9e0a2e1f597b4efc@SN2PR03MB077.namprd03.prod.outlook.com>
In-Reply-To: <5d8123dac718421a9e0a2e1f597b4efc@SN2PR03MB077.namprd03.prod.outlook.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------070901000502050802010206"
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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: Sat, 06 Jul 2013 00:09:39 -0000

This is a multi-part message in MIME format.
--------------070901000502050802010206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Sorry, I read your wording to suggest only binding the server. As you
explain things, I fully agree.


On 06/07/13 1:32, Dmitry Anipko wrote:
> >>If you look at malicious servers, does it matter what the server is
> allowed to do? It might be better to state what the client may accept?
>
> Yes, that's what I meant with "allowed" - that the client would have
> to validate against that limit, and either ignore the invalid message,
> or cap the value to the max allowed.
> ------------------------------------------------------------------------
> *From:* dhcwg-bounces@ietf.org  on behalf of
> Sten Carlsen 
> *Sent:* Friday, July 05, 2013 4:30 PM
> *To:* dhcwg@ietf.org
> *Subject:* Re: [dhcwg] Remidner - RE: WGLC on
> draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
>  
> If you look at malicious servers, does it matter what the server is
> allowed to do? It might be better to state what the client may accept?
>
>
> On 06/07/13 1:14, Dmitry Anipko wrote:
>> I've read the document and support moving it forward - IMO, it will help to reduce useless load on servers as well as save energy on resource constrained clients.
>>
>> One comment on the security section: do I understand correctly that if the malicious DHCP server sends an arbitrarily high value for either of the options, while the non-malicious DHCP server was temporarily down, then the client may not recover for a very long time? If such vector exists, would it be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is allowed to send to the client? (e.g. to 1h, or several hours or whatever)
>>
>> -Dmitry
>> ________________________________________
>> From: dhcwg-bounces@ietf.org  on behalf of Bernie Volz (volz) 
>> Sent: Friday, July 05, 2013 11:56 AM
>> To: dhcwg@ietf.org
>> Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
>>
>> Hi:
>>
>> Just a reminder about this WGLC. While it technically should have ended yesterday, Tomek and I will review on Monday to determine whether we have rough consensus for this to move forward. So, there is still time for you to get your comments in.
>>
>> While we've had some responses, more would be useful to help us gauge rough consensus.
>>
>> - Bernie
>>
>> -----Original Message-----
>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
>> Sent: Thursday, June 20, 2013 12:23 PM
>> To: dhcwg@ietf.org WG
>> Cc: Ralph Droms; Ted Lemon
>> Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
>>
>> On 20.06.2013 17:11, Ralph Droms wrote:
>>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:
>>>> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
>>>> last-call it now?
>>> OK with me.
>> My understanding is that under normal circumstances chairs cannot just announce WGLC on their own. They can do so if authors or editors state the the draft is ready and chairs concur with that opinion. Anyway, here it goes:
>>
>> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
>> feels it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.
>>
>> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control SOLICIT and INFORMATION-REQUEST message retransmissions and define a mechanism for server to override client's default values. There is a document in v6ops about basic requirements for IPv6 CE routers that depends on this work.
>>
>> At the time of this writing, there is no IPR reported against this draft.
>>
>> Bernie and I will evaluate consensus after 2013-07-04.
>>
>> Thanks,
>> Bernie & Tomek
>> _______________________________________________
>> 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
>
> -- 
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>        "MALE BOVINE MANURE!!!"

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


--------------070901000502050802010206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Sorry, I read your wording to suggest only binding the server. As
    you explain things, I fully agree.

    

    

    
On 06/07/13 1:32, Dmitry Anipko wrote:

    

    

      
      
      

        >>If you look at
          malicious servers, does it matter what the server is allowed
          to do? It might be better to state what the client may accept?
        


          

        
Yes, that's what I meant with
            "allowed" - that the client would have to validate against
            that limit, and either ignore the invalid message, or cap
            the value to the max allowed.

          
          

            

            
From: dhcwg-bounces@ietf.org
                <dhcwg-bounces@ietf.org> on behalf of Sten Carlsen
                <stenc@s-carlsen.dk>

                Sent: Friday, July 05, 2013 4:30 PM

                To: dhcwg@ietf.org

                Subject: Re: [dhcwg] Remidner - RE: WGLC on
                draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by
                July 4
              
 

            

            
If you look at malicious servers, does it matter what
              the server is allowed to do? It might be better to state
              what the client may accept?

              

              

              
On 06/07/13 1:14, Dmitry
                Anipko wrote:

              

              

                
I've read the document and support moving it forward - IMO, it will help to reduce useless load on servers as well as save energy on resource constrained clients.

One comment on the security section: do I understand correctly that if the malicious DHCP server sends an arbitrarily high value for either of the options, while the non-malicious DHCP server was temporarily down, then the client may not recover for a very long time? If such vector exists, would it be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT values the server is allowed to send to the client? (e.g. to 1h, or several hours or whatever)

-Dmitry
________________________________________
From: dhcwg-bounces@ietf.org <dhcwg-bounces@ietf.org> on behalf of Bernie Volz (volz) <volz@cisco.com>
Sent: Friday, July 05, 2013 11:56 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

Hi:

Just a reminder about this WGLC. While it technically should have ended yesterday, Tomek and I will review on Monday to determine whether we have rough consensus for this to move forward. So, there is still time for you to get your comments in.

While we've had some responses, more would be useful to help us gauge rough consensus.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Thursday, June 20, 2013 12:23 PM
To: dhcwg@ietf.org WG
Cc: Ralph Droms; Ted Lemon
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

On 20.06.2013 17:11, Ralph Droms wrote:


                

                  
On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:


                  

                    
Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
last-call it now?


                  

                  
OK with me.


                

                
My understanding is that under normal circumstances chairs cannot just announce WGLC on their own. They can do so if authors or editors state the the draft is ready and chairs concur with that opinion. Anyway, here it goes:

Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
feels it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.

This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control SOLICIT and INFORMATION-REQUEST message retransmissions and define a mechanism for server to override client's default values. There is a document in v6ops about basic requirements for IPv6 CE routers that depends on this work.

At the time of this writing, there is no IPR reported against this draft.

Bernie and I will evaluate consensus after 2013-07-04.

Thanks,
Bernie & Tomek
_______________________________________________
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


              

              

              
-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


            

          

        

      

    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


  


--------------070901000502050802010206--

From john_brzozowski@cable.comcast.com  Mon Jul  8 05:50: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 AA01A21F99E8 for ; Mon,  8 Jul 2013 05:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.897
X-Spam-Level: 
X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxGgDjxFX5qE for ; Mon,  8 Jul 2013 05:50:37 -0700 (PDT)
Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1821F99AB for ; Mon,  8 Jul 2013 05:50:36 -0700 (PDT)
Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP  id 97wm3m1.57785641; Mon, 08 Jul 2013 08:48:39 -0400
Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 8 Jul 2013 08:50:31 -0400
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Mon, 8 Jul 2013 08:50:30 -0400
From: "Brzozowski, John" 
To: "Bernie Volz (volz)" , Tomasz Mrugalski 
Thread-Topic: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOe9m6jLkzxSdBEEeTILd5zljGjw==
Date: Mon, 8 Jul 2013 12:50:29 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [68.87.16.248]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Remidner - RE: WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 08 Jul 2013 12:50:43 -0000

Bernie, Tomasz,

The deadline has passed and we had some reasonable exchanges on this
draft.  I do not recall seeing any opposition to advancing the same.  What
is your assessment?

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
o) 609-377-6594
w) www.comcast6.net
e) john_brzozowski@cable.comcast.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D






-----Original Message-----
From: Dmitry Anipko 
Date: Friday, July 5, 2013 7:14 PM
To: Bernie Volz , dhc WG 
Subject: Re: [dhcwg] Remidner - RE: WGLC on
draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

>I've read the document and support moving it forward - IMO, it will help
>to reduce useless load on servers as well as save energy on resource
>constrained clients.
>
>One comment on the security section: do I understand correctly that if
>the malicious DHCP server sends an arbitrarily high value for either of
>the options, while the non-malicious DHCP server was temporarily down,
>then the client may not recover for a very long time? If such vector
>exists, would it be reasonable to limit the max INF_MAX_RT/SOL_MAX_RT
>values the server is allowed to send to the client? (e.g. to 1h, or
>several hours or whatever)
>
>-Dmitry
>________________________________________
>From: dhcwg-bounces@ietf.org  on behalf of Bernie
>Volz (volz) 
>Sent: Friday, July 05, 2013 11:56 AM
>To: dhcwg@ietf.org
>Subject: [dhcwg] Remidner - RE: WGLC on
>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
>
>Hi:
>
>Just a reminder about this WGLC. While it technically should have ended
>yesterday, Tomek and I will review on Monday to determine whether we have
>rough consensus for this to move forward. So, there is still time for you
>to get your comments in.
>
>While we've had some responses, more would be useful to help us gauge
>rough consensus.
>
>- Bernie
>
>-----Original Message-----
>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
>Tomek Mrugalski
>Sent: Thursday, June 20, 2013 12:23 PM
>To: dhcwg@ietf.org WG
>Cc: Ralph Droms; Ted Lemon
>Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
>respond by July 4
>
>On 20.06.2013 17:11, Ralph Droms wrote:
>> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:
>>> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
>>> last-call it now?
>>
>> OK with me.
>My understanding is that under normal circumstances chairs cannot just
>announce WGLC on their own. They can do so if authors or editors state
>the the draft is ready and chairs concur with that opinion. Anyway, here
>it goes:
>
>Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
>(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
>feels it's ready for work group last call. Please review this draft and
>indicate whether or not you feel it is ready to be published.
>
>This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that
>control SOLICIT and INFORMATION-REQUEST message retransmissions and
>define a mechanism for server to override client's default values. There
>is a document in v6ops about basic requirements for IPv6 CE routers that
>depends on this work.
>
>At the time of this writing, there is no IPR reported against this draft.
>
>Bernie and I will evaluate consensus after 2013-07-04.
>
>Thanks,
>Bernie & Tomek
>_______________________________________________
>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 tomasz.mrugalski@gmail.com  Mon Jul  8 06:32: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 7759621F9A3B for ; Mon,  8 Jul 2013 06:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBf5yl8Ynj+f for ; Mon,  8 Jul 2013 06:32:42 -0700 (PDT)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77921F9A2E for ; Mon,  8 Jul 2013 06:32:42 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id jm2so1847552bkc.2 for ; Mon, 08 Jul 2013 06:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=9bwqjH+mS7dj+AGx8XilndHJ51YKrJs55diCUnrQrJU=; b=ivgrfHLQXjiO71LvVPKfHI2QEyGAn1uWElB4nGxU/yCKCxbeWmmpePNbY4wT1xadwa pLq2cSk3xWQ/Spla6GrjrwVWl63IPOKpotGvWSmNXk6ed89XwN9+P+V8Ebf8HVLt1dEe izuD4LY4ESJ01THl7FMT8hMmByEYhhI7Dsscg+/3VR/UdXJVMHvi7B7HsoL2+5+bRgnp iaAg/AvRHE8hPC4VlJ1bfTX8KmZK/afejYngLkyLUvY6ufavcevlh68+JkKeG/S97zCV AhmW/IIcgE3xHEqwNx7JSVywUC3NSqBAAOtYNQaO2J8UNGY4Aeel3zsNG1lU1+K5ZtHE G0/A==
X-Received: by 10.204.185.135 with SMTP id co7mr3375383bkb.91.1373290361441; Mon, 08 Jul 2013 06:32:41 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id kz11sm4500719bkb.11.2013.07.08.06.32.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 06:32:39 -0700 (PDT)
Message-ID: <51DABF73.7060300@gmail.com>
Date: Mon, 08 Jul 2013 15:32:35 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "dhcwg@ietf.org WG" 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com>
In-Reply-To: <51C32C73.1010203@gmail.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130708153235128
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 08 Jul 2013 13:32:43 -0000

On 20.06.2013 18:23, Tomek Mrugalski wrote:
> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
> feels it's ready for work group last call. Please review this draft and
> indicate whether or not you feel it is ready to be published.
> 
> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that
> control SOLICIT and INFORMATION-REQUEST message retransmissions and
> define a mechanism for server to override client's default values. There
> is a document in v6ops about basic requirements for IPv6 CE routers that
> depends on this work.
> 
> At the time of this writing, there is no IPR reported against this draft.
> 
> Bernie and I will evaluate consensus after 2013-07-04.
Very useful draft. I strongly support this work moving forward. I do
have some comments, though.

1. Clarifying question regarding text:

   As a result of receiving this
   option, the DHCPv6 client MUST NOT send any Solicit messages more
   frequently than allowed by the retransmission mechanism defined in
   sections 17.1.2 and 14 of RFC 3315

The (updated) section 17.1.2 says that SOLMAXRT is now 3600 (seconds).
Any value received in the option that is smaller than 3600 will mean
that the SOLICIT messages would be sent more frequently, thus must be
ignored. Does it mean that allowed range of values is 3600 - 2^32-2 ?

I'm somewhat ok with that, but I would prefer that there would be an
ability to revert to current behaviour, i.e. configure value of SOLMAXRT
option to 120, so old and new clients would behave the same way.

In any case, I think the allowed values should be explicitly specified
for both options. I would also consider the upper end of possible ranges
here. 2^32 seconds is around 136 years, so perhaps limiting the upper
value is a good idea as well? Speaking of big numbers, section 5.6 of
3315 says that 0xffffffff means infinity (I agree that it is somewhat
debatable if that applies to timers, but it's a matter of
interpretation). Is it allowed value here? That would mean that this
draft allows tweaking backoff mechanism to essentially have no upper
threshold. I prefer to not have a solution that can be told to count to
infinity.

2. Section 8 must be updated to cover also INF_MAX_RT value.

3. RFC3315 mentions client restarting configuration process in various
events (NotOnLink status received, received REPLY for INF-Request failed
validation, link change etc.) and there are operational events that also
trigger it: service restart, sleep/resume, device reboot etc. It is not
clear whether client should attempt to store the INF_MAX_RT and
SOL_MAX_RT values across those events? If not, at what situation should
it revert back to default (3600) values? I think it would be good to
clarify that.

4. It is not very well specified what should the client do if it
receives several ADVERTISEs, each with different SOLMAXRT (or INFMAXRT)?
I'm tempted to assume that according to the current text, it must
process them in the order in which they appear. That may not be the best
thing to do. Perhaps clarifying text about using exactly one value from
the received advertises could be helpful? I agree that having two
servers on the same link advertising different values is a bit uncommon
(configuration error or a rogue server), but clients should be able to
behave consistently in such case.

5. The text does not include Client and Server behaviour sections, as
recommended by option-guidelines-12, Section 21. I agree that this draft
is very simple, but it would be good to follow those recommendations if
possible.

6. Is RFC3633 reference really normative here? I think it should be
informative.

7. Ralph already mentioned his plan to have the name updated to reflect
the addition of INF_MAX_RT.

8. The discussion in Security considerations is not precise. According
to last paragraph of section 4 ("If a DHCPv6 client receives a message
containing a SOL_MAX_RT option, the client MUST set its internal
SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT option.").
Note that this sentence applies to all received messages, including
non-selected Advertises. So whether the value sent by legitimate or
rogue server will be used by the server, depends on the order of
received messages. Also see my comment #4.

Hope that helps,
Tomek


From rdroms.ietf@gmail.com  Mon Jul  8 12:25: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 4443721F99F2 for ; Mon,  8 Jul 2013 12:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level: 
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKPVdyoUYQgi for ; Mon,  8 Jul 2013 12:25:41 -0700 (PDT)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7C721F8BE6 for ; Mon,  8 Jul 2013 12:25:15 -0700 (PDT)
Received: by mail-vb0-f49.google.com with SMTP id 12so3697172vbf.22 for ; Mon, 08 Jul 2013 12:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WL0sDc5dVGJn10HsTao0AlqFGkfo1BTItrCESqtVSUA=; b=fWAP+KXHRvNhHSldCID9PPu/0GI301dt1D53gBJIyermomXzhk3Tonn8/w6FhXLJmv /p1VQ78QQO0sf4xi7bZutfel7Z2f8/cSBT5ZHEZmRPSMPtV4GaXIZOb9BCICskzYEI4R cZFdOgI0lEs78ZmIOlxRf8rbxqEpq0/TidVkxtlBKlA5N7iAcQm0dllsLLR94yXLQNao lopmr1w3VpRLFFgeEA21R6PTT58DAmVX9YukMdeBGBvlf9A74sZe8YxoBtHvHxMOerDs Si2YvU4/2lLUXPUm3dql3+OY+2Iq+Nx6DNctIA8qGLrZ4SVbFjnx1OZSSRsALbl90XiJ 6CKg==
X-Received: by 10.58.211.7 with SMTP id my7mr14589012vec.54.1373311514707; Mon, 08 Jul 2013 12:25:14 -0700 (PDT)
Received: from dhcp-i7prhfzrgrwle.d.cisco.com ([2001:420:2c52:1316:f9c6:c3df:d81:5cf6]) by mx.google.com with ESMTPSA id ih10sm17057773vdb.1.2013.07.08.12.25.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 12:25:12 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <51DABF73.7060300@gmail.com>
Date: Mon, 8 Jul 2013 15:25:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com> <51DABF73.7060300@gmail.com>
To: Tomek Mrugalski 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" , Droms Ralph 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 08 Jul 2013 19:25:42 -0000

On Jul 8, 2013, at 9:32 AM 7/8/13, Tomek Mrugalski =
 wrote:

> On 20.06.2013 18:23, Tomek Mrugalski wrote:
>> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
>> feels it's ready for work group last call. Please review this draft =
and
>> indicate whether or not you feel it is ready to be published.
>>=20
>> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that
>> control SOLICIT and INFORMATION-REQUEST message retransmissions and
>> define a mechanism for server to override client's default values. =
There
>> is a document in v6ops about basic requirements for IPv6 CE routers =
that
>> depends on this work.
>>=20
>> At the time of this writing, there is no IPR reported against this =
draft.
>>=20
>> Bernie and I will evaluate consensus after 2013-07-04.
> Very useful draft. I strongly support this work moving forward. I do
> have some comments, though.
>=20
> 1. Clarifying question regarding text:
>=20
>   As a result of receiving this
>   option, the DHCPv6 client MUST NOT send any Solicit messages more
>   frequently than allowed by the retransmission mechanism defined in
>   sections 17.1.2 and 14 of RFC 3315
>=20
> The (updated) section 17.1.2 says that SOLMAXRT is now 3600 (seconds).
> Any value received in the option that is smaller than 3600 will mean
> that the SOLICIT messages would be sent more frequently, thus must be
> ignored. Does it mean that allowed range of values is 3600 - 2^32-2 ?

That paragraph isn't well written.  How about:

   If a DHCPv6 client receives a message containing a SOL_MAX_RT
   option, the client MUST set its internal SOL_MAX_RT parameter to
   the value contained in the SOL_MAX_RT option.  This value of
   SOL_MAX_RT is then used by the retransmission mechanism defined in
   sections 17.1.2 and 14 of RFC 3315 [RFC3315].

...which would allow for values of SOL_MAX_RT smaller than the new =
default of 3600.

>=20
> I'm somewhat ok with that, but I would prefer that there would be an
> ability to revert to current behaviour, i.e. configure value of =
SOLMAXRT
> option to 120, so old and new clients would behave the same way.

Does the new text address this issue by allowing a value of 120 in the =
SOL_MAX_RT option?
>=20
> In any case, I think the allowed values should be explicitly specified
> for both options. I would also consider the upper end of possible =
ranges
> here. 2^32 seconds is around 136 years, so perhaps limiting the upper
> value is a good idea as well? Speaking of big numbers, section 5.6 of
> 3315 says that 0xffffffff means infinity (I agree that it is somewhat
> debatable if that applies to timers, but it's a matter of
> interpretation). Is it allowed value here? That would mean that this
> draft allows tweaking backoff mechanism to essentially have no upper
> threshold. I prefer to not have a solution that can be told to count =
to
> infinity.

In my opinion, the additional constraints aren't necessary and it would =
be better to minimize the changes relative to RFC 3315.

>=20
> 2. Section 8 must be updated to cover also INF_MAX_RT value.

e.g.:

8.  IANA Considerations

   IANA is requested to assign option codes from the "DHCP Option
   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
>=20
> 3. RFC3315 mentions client restarting configuration process in various
> events (NotOnLink status received, received REPLY for INF-Request =
failed
> validation, link change etc.) and there are operational events that =
also
> trigger it: service restart, sleep/resume, device reboot etc. It is =
not
> clear whether client should attempt to store the INF_MAX_RT and
> SOL_MAX_RT values across those events? If not, at what situation =
should
> it revert back to default (3600) values? I think it would be good to
> clarify that.


>=20
> 4. It is not very well specified what should the client do if it
> receives several ADVERTISEs, each with different SOLMAXRT (or =
INFMAXRT)?
> I'm tempted to assume that according to the current text, it must
> process them in the order in which they appear. That may not be the =
best
> thing to do. Perhaps clarifying text about using exactly one value =
from
> the received advertises could be helpful? I agree that having two
> servers on the same link advertising different values is a bit =
uncommon
> (configuration error or a rogue server), but clients should be able to
> behave consistently in such case.

Is this situation different from all the other options that might appear =
in messages from multiple servers?

There's a hidden point in your question: does this option apply when =
received in an Advertise message or just when received in a Reply =
message?

>=20
> 5. The text does not include Client and Server behaviour sections, as
> recommended by option-guidelines-12, Section 21. I agree that this =
draft
> is very simple, but it would be good to follow those recommendations =
if
> possible.

Aw, I was trying to keep this draft as simple as possible.  I'll rewrite =
the draft if the consensus is that it should follow the guidelines but =
I'd prefer not to if possible.  Sorry to be lazy (and to resort to a bit =
of blackmail), but the reality is that rewriting for Client and Server =
behavior sections is likely to delay the document...
>=20
> 6. Is RFC3633 reference really normative here? I think it should be
> informative.

Agreed.

>=20
> 7. Ralph already mentioned his plan to have the name updated to =
reflect
> the addition of INF_MAX_RT.

"Modifications to Default Values of SOL_MAX_RT and INF_MAX_RT"
>=20
> 8. The discussion in Security considerations is not precise. According
> to last paragraph of section 4 ("If a DHCPv6 client receives a message
> containing a SOL_MAX_RT option, the client MUST set its internal
> SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT =
option.").
> Note that this sentence applies to all received messages, including
> non-selected Advertises. So whether the value sent by legitimate or
> rogue server will be used by the server, depends on the order of
> received messages. Also see my comment #4.

Yeah, so perhaps "receives a message containing a SOL_MAX_RT option" =
should be constrained to just "receives a Reply message containing a =
SOL_MAX_RT option"?

>=20
> Hope that helps,
> Tomek

Very helpful and thanks for your thorough and careful review.

- Ralph

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


From sarikaya2012@gmail.com  Mon Jul  8 12:38: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 EE25B21F9D68 for ; Mon,  8 Jul 2013 12:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.455
X-Spam-Level: 
X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91gzSIbjmjMI for ; Mon,  8 Jul 2013 12:38:46 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id D547221F9D65 for ; Mon,  8 Jul 2013 12:38:44 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id y6so4037830lbh.9 for ; Mon, 08 Jul 2013 12:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=vYWwrQsUbgVLdzEQJi7QhB6KbBifXIj9ySkcKOwU5O4=; b=bZHTxN1Lux6ekjWyi2vtbwdzMJ6pF50YTPBvbfsDwk0vpYu9kjCBfEa668Yy+q3w5j U96jFKesQ3haiU2rjXfGIEQnNeauVlbj56MNW5KNTPgkOMxNgJX+71GyX79SVaoKve05 tqR1FHj5hkDWxBASRgqoAz7rss+uqC8zdtqaQJ1DMLrbpnlzwJbxzMOP3jDNJah6jBf9 YZEi7q0jtOele4UJeDqaeh8TL2SVN65xb9aK+tAAeg+2wGUVY7at7KHILGFScc+ZygZv 2kPBC2sRvF4OuWX9WIfDeFYBYZqORPAy2MbPePEGadYXshMhm+iM2A2JgZZsOgVx4np7 F1Ew==
MIME-Version: 1.0
X-Received: by 10.112.13.199 with SMTP id j7mr11625745lbc.25.1373312323723; Mon, 08 Jul 2013 12:38:43 -0700 (PDT)
Received: by 10.114.176.37 with HTTP; Mon, 8 Jul 2013 12:38:43 -0700 (PDT)
In-Reply-To: <20130708193730.32338.54318.idtracker@ietfa.amsl.com>
References: <20130708193730.32338.54318.idtracker@ietfa.amsl.com>
Date: Mon, 8 Jul 2013 14:38:43 -0500
Message-ID: 
From: Behcet Sarikaya 
To: dhcwg@ietf.org
Content-Type: multipart/alternative; boundary=001a11c3cb9e38a75804e1053137
Subject: [dhcwg] New Version Notification for draft-sarikaya-dhc-vxlan-multicast-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Jul 2013 19:38:47 -0000

--001a11c3cb9e38a75804e1053137
Content-Type: text/plain; charset=ISO-8859-1

A new version of I-D, draft-sarikaya-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename:        draft-sarikaya-dhc-vxlan-multicast
Revision:        00
Title:           DHCP Options for Configuring Multicast Addresses in VXLAN
Creation date:   2013-07-08
Group:           Individual Submission
Number of pages: 12
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-dhc-vxlan-multicast-00.txt
Status:
http://datatracker.ietf.org/doc/draft-sarikaya-dhc-vxlan-multicast
Htmlized:
http://tools.ietf.org/html/draft-sarikaya-dhc-vxlan-multicast-00


Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning
   multicast addresses for the Tunnel End Point in the Virtual
   eXtensible Local Area Network (VXLAN) environments.  New DHCP options
   are defined which allow a VXLAN Tunnel End Point to request any
   source multicast address for the newly created virtual machine, the
   address of the Rendezvous Point (RP) and possibly address(es) for the
   virtual machine.




The IETF Secretariat

--001a11c3cb9e38a75804e1053137
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




A new version of I-D, draft-sarikaya-dhc-vxlan-multicast-00.txt

has been successfully submitted by Behcet Sarikaya and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-sarikaya-dhc-vxlan-multicast

Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 DHCP Options for Configuring Multicast Addresses=
 in VXLAN

Creation date: =A0 2013-07-08

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 12

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie=
tf.org/internet-drafts/draft-sarikaya-dhc-vxlan-multicast-00.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or=
g/doc/draft-sarikaya-dhc-vxlan-multicast

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dra=
ft-sarikaya-dhc-vxlan-multicast-00





Abstract:

=A0 =A0This document defines DHCPv4 and DHCPv6 options for assigning

=A0 =A0multicast addresses for the Tunnel End Point in the Virtual

=A0 =A0eXtensible Local Area Network (VXLAN) environments. =A0New DHCP opti=
ons

=A0 =A0are defined which allow a VXLAN Tunnel End Point to request any

=A0 =A0source multicast address for the newly created virtual machine, the<=
br>
=A0 =A0address of the Rendezvous Point (RP) and possibly address(es) for th=
e

=A0 =A0virtual machine.









The IETF Secretariat







--001a11c3cb9e38a75804e1053137--

From john_brzozowski@cable.comcast.com  Mon Jul  8 17:18: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 E4D9D21F9A4A for ; Mon,  8 Jul 2013 17:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.797
X-Spam-Level: 
X-Spam-Status: No, score=-103.797 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDse6gjDap0J for ; Mon,  8 Jul 2013 17:18:27 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 901BA21F9A26 for ; Mon,  8 Jul 2013 17:18:27 -0700 (PDT)
Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.81424314; Mon, 08 Jul 2013 18:16:47 -0600
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 8 Jul 2013 20:18:22 -0400
From: "Brzozowski, John" 
To: Ralph Droms , Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfDnRnUZzNLAd0UOoNaBD0vF7Qw==
Date: Tue, 9 Jul 2013 00:18:21 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [68.87.16.246]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <187F4CC152803449A8D100E7642DAA92@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 00:18:33 -0000

See below.


John
-----Original Message-----
From: Ralph Droms 
Date: Monday, July 8, 2013 3:25 PM
To: Tomasz Mrugalski 
Cc: dhc WG , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
-	respond by July 4

>
>On Jul 8, 2013, at 9:32 AM 7/8/13, Tomek Mrugalski
> wrote:
>
>> On 20.06.2013 18:23, Tomek Mrugalski wrote:
>>> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
>>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
>>> feels it's ready for work group last call. Please review this draft and
>>> indicate whether or not you feel it is ready to be published.
>>>=20
>>> This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that
>>> control SOLICIT and INFORMATION-REQUEST message retransmissions and
>>> define a mechanism for server to override client's default values.
>>>There
>>> is a document in v6ops about basic requirements for IPv6 CE routers
>>>that
>>> depends on this work.
>>>=20
>>> At the time of this writing, there is no IPR reported against this
>>>draft.
>>>=20
>>> Bernie and I will evaluate consensus after 2013-07-04.
>> Very useful draft. I strongly support this work moving forward. I do
>> have some comments, though.
>>=20
>> 1. Clarifying question regarding text:
>>=20
>>   As a result of receiving this
>>   option, the DHCPv6 client MUST NOT send any Solicit messages more
>>   frequently than allowed by the retransmission mechanism defined in
>>   sections 17.1.2 and 14 of RFC 3315
>>=20
>> The (updated) section 17.1.2 says that SOLMAXRT is now 3600 (seconds).
>> Any value received in the option that is smaller than 3600 will mean
>> that the SOLICIT messages would be sent more frequently, thus must be
>> ignored. Does it mean that allowed range of values is 3600 - 2^32-2 ?
>
>That paragraph isn't well written.  How about:
>
>   If a DHCPv6 client receives a message containing a SOL_MAX_RT
>   option, the client MUST set its internal SOL_MAX_RT parameter to
>   the value contained in the SOL_MAX_RT option.  This value of
>   SOL_MAX_RT is then used by the retransmission mechanism defined in
>   sections 17.1.2 and 14 of RFC 3315 [RFC3315].
>
>...which would allow for values of SOL_MAX_RT smaller than the new
>default of 3600.
>
>>=20
>> I'm somewhat ok with that, but I would prefer that there would be an
>> ability to revert to current behaviour, i.e. configure value of SOLMAXRT
>> option to 120, so old and new clients would behave the same way.
>
>Does the new text address this issue by allowing a value of 120 in the
>SOL_MAX_RT option?
[jjmb] the new text Ralph proposed seems to address Tomasz's comment well.

>>=20
>> In any case, I think the allowed values should be explicitly specified
>> for both options. I would also consider the upper end of possible ranges
>> here. 2^32 seconds is around 136 years, so perhaps limiting the upper
>> value is a good idea as well? Speaking of big numbers, section 5.6 of
>> 3315 says that 0xffffffff means infinity (I agree that it is somewhat
>> debatable if that applies to timers, but it's a matter of
>> interpretation). Is it allowed value here? That would mean that this
>> draft allows tweaking backoff mechanism to essentially have no upper
>> threshold. I prefer to not have a solution that can be told to count to
>> infinity.
>
>In my opinion, the additional constraints aren't necessary and it would
>be better to minimize the changes relative to RFC 3315.
[jjmb] I would agree.
>
>>=20
>> 2. Section 8 must be updated to cover also INF_MAX_RT value.
>
>e.g.:
>
>8.  IANA Considerations
>
>   IANA is requested to assign option codes from the "DHCP Option
>   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
>>=20
>> 3. RFC3315 mentions client restarting configuration process in various
>> events (NotOnLink status received, received REPLY for INF-Request failed
>> validation, link change etc.) and there are operational events that also
>> trigger it: service restart, sleep/resume, device reboot etc. It is not
>> clear whether client should attempt to store the INF_MAX_RT and
>> SOL_MAX_RT values across those events? If not, at what situation should
>> it revert back to default (3600) values? I think it would be good to
>> clarify that.
>
>
>>=20
>> 4. It is not very well specified what should the client do if it
>> receives several ADVERTISEs, each with different SOLMAXRT (or INFMAXRT)?
>> I'm tempted to assume that according to the current text, it must
>> process them in the order in which they appear. That may not be the best
>> thing to do. Perhaps clarifying text about using exactly one value from
>> the received advertises could be helpful? I agree that having two
>> servers on the same link advertising different values is a bit uncommon
>> (configuration error or a rogue server), but clients should be able to
>> behave consistently in such case.
>
>Is this situation different from all the other options that might appear
>in messages from multiple servers?
>
>There's a hidden point in your question: does this option apply when
>received in an Advertise message or just when received in a Reply message?
[jjmb] it seems the reply rules here like many other aspects of the DHCPv6
exchange.

>
>>=20
>> 5. The text does not include Client and Server behaviour sections, as
>> recommended by option-guidelines-12, Section 21. I agree that this draft
>> is very simple, but it would be good to follow those recommendations if
>> possible.
>
>Aw, I was trying to keep this draft as simple as possible.  I'll rewrite
>the draft if the consensus is that it should follow the guidelines but
>I'd prefer not to if possible.  Sorry to be lazy (and to resort to a bit
>of blackmail), but the reality is that rewriting for Client and Server
>behavior sections is likely to delay the document...
[jjmb] I agree tre-writing should not be required here, I do not see the
need.

>>=20
>> 6. Is RFC3633 reference really normative here? I think it should be
>> informative.
>
>Agreed.
>
>>=20
>> 7. Ralph already mentioned his plan to have the name updated to reflect
>> the addition of INF_MAX_RT.
>
>"Modifications to Default Values of SOL_MAX_RT and INF_MAX_RT"
>>=20
>> 8. The discussion in Security considerations is not precise. According
>> to last paragraph of section 4 ("If a DHCPv6 client receives a message
>> containing a SOL_MAX_RT option, the client MUST set its internal
>> SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT option.").
>> Note that this sentence applies to all received messages, including
>> non-selected Advertises. So whether the value sent by legitimate or
>> rogue server will be used by the server, depends on the order of
>> received messages. Also see my comment #4.
>
>Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
>should be constrained to just "receives a Reply message containing a
>SOL_MAX_RT option"?
[jjmb] as I stated above the reply is ultimately what should be used in
the exchange.

>
>>=20
>> Hope that helps,
>> Tomek
>
>Very helpful and thanks for your thorough and careful review.
>
>- Ralph
>
>>=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


From tomasz.mrugalski@gmail.com  Tue Jul  9 05:00: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 5CD2D21F9FAA for ; Tue,  9 Jul 2013 05:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJMYHMwSo8Hk for ; Tue,  9 Jul 2013 05:00:44 -0700 (PDT)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id ED60E21F9FBE for ; Tue,  9 Jul 2013 05:00:41 -0700 (PDT)
Received: by mail-bk0-f54.google.com with SMTP id it16so2329165bkc.13 for ; Tue, 09 Jul 2013 05:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=W556dZerc1+0orKIYkE8HkB1VeqwNnHZLlrcEOKKNt4=; b=Q8Fh7qRgU3jiuWdpReuO6zqMqqwuQBDQgZB5wxESEKYcoCXB4eeYgGicYxbNLuyPkL a/KG1brVO0li71zcdtr3uEVn+kFcEzRE7theHhayiFgBGleHBBxiaFjkyFyhyRvkeUOP ltJGQgL15UE0hxnCvjKp3oyovpRzEF+8y2ixzX9zsGVk6Ve64AxUYfVW8lS4lPRtP0xT /1W/aF5OqhFUTUXT+ayzTHHDezEml1nXt6hv+yV5+NQ29dJjFzwfRtCcWaLVxRnvsuVh 4sbPU0rbQL6prURKzaPNxY/O9BeaI4BJnAjJ1Qe4hm54OlG/4ylH01q3H168Z/ZzeDqj xycQ==
X-Received: by 10.204.186.141 with SMTP id cs13mr4300234bkb.34.1373371241000;  Tue, 09 Jul 2013 05:00:41 -0700 (PDT)
Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id cy5sm5637757bkb.1.2013.07.09.05.00.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 05:00:39 -0700 (PDT)
Message-ID: <51DBFB65.2000309@gmail.com>
Date: Tue, 09 Jul 2013 14:00:37 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ralph Droms 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com> <51DABF73.7060300@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: multipart/mixed; boundary="------------050303090605000001030301"
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 12:00:46 -0000

This is a multi-part message in MIME format.
--------------050303090605000001030301
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 13-07-08 21:25, Ralph Droms wrote:
> On Jul 8, 2013, at 9:32 AM 7/8/13, Tomek Mrugalski
>  wrote:
>> 1. Clarifying question regarding text:
>> 
>> As a result of receiving this option, the DHCPv6 client MUST NOT
>> send any Solicit messages more frequently than allowed by the
>> retransmission mechanism defined in sections 17.1.2 and 14 of RFC
>> 3315
>> 
>> The (updated) section 17.1.2 says that SOLMAXRT is now 3600
>> (seconds). Any value received in the option that is smaller than
>> 3600 will mean that the SOLICIT messages would be sent more
>> frequently, thus must be ignored. Does it mean that allowed range
>> of values is 3600 - 2^32-2 ?
> 
> That paragraph isn't well written.  How about:
> 
> If a DHCPv6 client receives a message containing a SOL_MAX_RT option,
> the client MUST set its internal SOL_MAX_RT parameter to the value
> contained in the SOL_MAX_RT option.  This value of SOL_MAX_RT is then
> used by the retransmission mechanism defined in sections 17.1.2 and
> 14 of RFC 3315 [RFC3315].
> 
> ...which would allow for values of SOL_MAX_RT smaller than the new
> default of 3600.
That will work. But there's a potential danger of setting both timers to
too low value. Rogue server set in IPv4-only network could set both to 1
and then you'd have a nice packet storm in your network. On the other
hand I don't think it's a big deal as you can do the same now with T1=1
and very long lifetimes.

>> I'm somewhat ok with that, but I would prefer that there would be
>> an ability to revert to current behaviour, i.e. configure value of
>> SOLMAXRT option to 120, so old and new clients would behave the
>> same way.
> 
> Does the new text address this issue by allowing a value of 120 in
> the SOL_MAX_RT option?
Yes, thank you.

>> In any case, I think the allowed values should be explicitly
>> specified for both options. I would also consider the upper end of
>> possible ranges here. 2^32 seconds is around 136 years, so perhaps
>> limiting the upper value is a good idea as well? Speaking of big
>> numbers, section 5.6 of 3315 says that 0xffffffff means infinity (I
>> agree that it is somewhat debatable if that applies to timers, but
>> it's a matter of interpretation). Is it allowed value here? That
>> would mean that this draft allows tweaking backoff mechanism to
>> essentially have no upper threshold. I prefer to not have a
>> solution that can be told to count to infinity.
> In my opinion, the additional constraints aren't necessary and it
> would be better to minimize the changes relative to RFC 3315.
Ok.

> 8.  IANA Considerations
> 
> IANA is requested to assign option codes from the "DHCP Option Codes"
> Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
That will work. Thanks.

>> 5. The text does not include Client and Server behaviour sections,
>> as recommended by option-guidelines-12, Section 21. I agree that
>> this draft is very simple, but it would be good to follow those
>> recommendations if possible.
> 
> Aw, I was trying to keep this draft as simple as possible.  I'll
> rewrite the draft if the consensus is that it should follow the
> guidelines but I'd prefer not to if possible.  Sorry to be lazy (and
> to resort to a bit of blackmail), but the reality is that rewriting
> for Client and Server behavior sections is likely to delay the
> document...
Nah, it won't delay anything. And I'm blackmail resistant. :) Please see
proposed XML attached with applied changes 1, 2, 5, 6, and 7. The only
outstanding issue is whether we want client to use SOL_MAX_RT and
INF_MAX_RT received in all messages or just REPLY. You may also look at
new nitpicks 9 and 10 below, if you think they are worth the effort.

If we go with REPLY only, we can remove almost all section 6, except
last NEW paragraph, so the draft becomes even simpler and changes to
3315 become smaller.

>> 7. Ralph already mentioned his plan to have the name updated to
>> reflect the addition of INF_MAX_RT.
> 
> "Modifications to Default Values of SOL_MAX_RT and INF_MAX_RT"
Sounds fine.

>> 8. The discussion in Security considerations is not precise.
>> According to last paragraph of section 4 ("If a DHCPv6 client
>> receives a message containing a SOL_MAX_RT option, the client MUST
>> set its internal SOL_MAX_RT parameter to the value contained in the
>> SOL_MAX_RT option."). Note that this sentence applies to all
>> received messages, including non-selected Advertises. So whether
>> the value sent by legitimate or rogue server will be used by the
>> server, depends on the order of received messages. Also see my
>> comment #4.
> Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
> should be constrained to just "receives a Reply message containing a
> SOL_MAX_RT option"?
That would work fine. One (minor) disadvantage is that with the current
text you can set up a dummy server that will send out NoAddsAvail and
longish SOL_MAX_RT/INF_MAX_RT if you don't want to be bothered with
DHCPv6 in your network and you want to limit the traffic. As I said
that's really minor disadvantage as the updated clients will go for 1
packet per hour and the old clients won't use SOL_MAX_RT anyway.

I have 2 other minor change proposals:

9. One other thing that occurred to me is possible addition of the
following text:

    Client also MAY include option SOL_MAX_RT in its SOLICIT,
    REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
    hint for the server regarding preferred option values.

I always liked the idea that DHCP allows negotiations between client and
server. Sadly, most implementations don't take advantage of such
capability. But if you don't like this concept, I'm ok with not adding it.

10. You mention in 2 places that the options must be sent as top-level
options, not sub-options. We had a discussion with Ted and Bernie
regarding vocabulary. Ted prefers sub-options to be used for options
that use private number spaces (like sub-options in DHCPv4) and use
"nested" or "encapsulated" for DHCPv6. "Encapsulated" is used in
RFC3315, but I think it's not a good name as it has overloaded meaning
(the other is what relays do with client messages). If it was up to me
to decide, I would go with "nested", but I'm ok with whatever WG decides
to use. This terminology is discussed in section 9 of option-guidelines.
I'll be more than happy to update it if needed.

Thanks for doing this work.
Tomek

--------------050303090605000001030301
Content-Type: text/xml;
 name="draft-ietf-dhc-dhcpv6-solmaxrt-update.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-ietf-dhc-dhcpv6-solmaxrt-update.xml"









]>























  

  

  
    

    Modification to Default Values of
    SOL_MAX_RT and INF_MAX_RT 

    

    

    
      Cisco Systems

      

        
          1414 Massachusetts Avenue

          

          Boxborough

          MA

          01719

          USA
        

        +1 978 936 1674

        rdroms@cisco.com

        
      

    

    

    

    

    Internet



    


    

    
      This document updates RFC 3315 by redefining the default
      values for SOL_MAX_RT and INF_MAX_RT, and defining options
      through which a DHCPv6 server can override the client's default
      value for SOL_MAX_RT and INF_MAX_RT with a new value.
    
  

  
    


      Section 5.5 of the DHCPv6
      specification defines the default values of SOL_MAX_RT
      and INF_MAX_RT to be 120 seconds.  In some circumstances, these
      defaults will lead to an unacceptably high volume of aggregated
      traffic at a DHCPv6 server.

      The change to SOL_MAX_RT is in response to DHCPv6 message
      rates observed at a DHCPv6 server in a deployment in which many
      DHCPv6 clients are sending Solicit messages but the DHCPv6
      server has been configured not to respond to those Solicit
      messages.  While no explicit observations of traffic due to
      INF_MAX_RT have been conducted, this document updates INF_MAX_RT
      for consistency with SOL_MAX_RT.
    


    

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119.
    


    

      This document changes section 5.5 of RFC 3315 as follows: 

      

        
        

      

      With this change, a DHCPv6 client that does not receive a
      satisfactory response will send Solicit or Information-request
      messages with the same initial frequency and exponential backoff
      as specified in sections 17.1.2 and 18.1.5 of RFC 3315.  However, the long term
      behavior of these DHCPv6 clients will be to send a Solicit or
      Information-request message every 3600 seconds rather than every
      120 seconds, significantly reducing the aggregated traffic at
      the DHCPv6 server.

    


    

      A DHCPv6 server sends the SOL_MAX_RT option to a client to
      override the default value of SOL_MAX_RT.  The value of
      SOL_MAX_RT in the option replaces the default value defined in
      .  One use for the
      SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which
      reduces the Solicit traffic from a client that has not received
      a response to its Solicit messages.

      The format of the SOL_MAX_RT option is:
      
      

	

	
      

      

    

  
    

      A DHCPv6 server sends the INF_MAX_RT option to a client to
      override the default value of INF_MAX_RT.  The value of
      INF_MAX_RT in the option replaces the default value defined in
      .  One use for the INF_MAX_RT
      option is to set a longer value for INF_MAX_RT, which reduces
      the Solicit traffic from a client that has not received a
      response to its Solicit messages.

      The format of the INF_MAX_RT option is:
      
      

	

	
      

      

    


    

      Update to RFC 3315, section
      17.1.3: 

      

	
	

	
      

      
      
      Update to RFC 3315, section
      17.2.2: 

      

	

	
      

      

      Add text to the end of section 14, clarifying client behavior
      while waiting for a response from a server:

      

	

	
      

      

    



    


      A DHCPv6 client MUST include the SOL_MAX_RT option code in an
      Option Request option in any
      message it sends.

      Client also MAY include option SOL_MAX_RT in its SOLICIT,
      REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
      hint for the server regarding preferred option values.
		
      If a DHCPv6 client receives a message containing a SOL_MAX_RT
      option, the client MUST set its internal SOL_MAX_RT parameter to
      the value contained in the SOL_MAX_RT option.  
      This value of
      SOL_MAX_RT is then used by the retransmission mechanism defined in
      sections 17.1.2 and 14 of RFC 3315.

      A DHCPv6 client MUST include the INF_MAX_RT option code in an
      Option Request option in any
      message it sends.

      Client also MAY include option SOL_MAX_RT in its SOLICIT,
      REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
      hint for the server regarding preferred option values.

      If a DHCPv6 client receives a message containing a INF_MAX_RT
      option, the client MUST set its internal INF_MAX_RT parameter to
      the value contained in the INF_MAX_RT option. 
      This value of
      INF_MAX_RT is then used by the retransmission mechanism defined in
      sections 18.1.5 and 14 of RFC 3315.
    


    

      Sections 17.2.2 and 18.2 of  govern
      server operation in regards to option assignment. As a convenience to
      the reader, we mention here that the server will send option SOL_MAX_RT
      and INF_MAX_RT only if configured with specific values for them and the
      client requested those options using Option Request Option.

      The DHCPv6 server MAY include the SOL_MAX_RT option in any
      response it sends to a client that has included the SOL_MAX_RT
      option code in an Option Request option.  The SOL_MAX_RT option
      is sent in the main body of the message to client, not as a
      sub-option in, e.g., an IA_NA, IA_TA
      or IA_PD option.

      The DHCPv6 server MAY include the INF_MAX_RT option in any
      response it sends to a client that has included the INF_MAX_RT
      option code in an Option Request option.  The INF_MAX_RT option
      is sent in the main body of the message to client, not as a
      sub-option in, e.g., an IA_NA, IA_TA
      or IA_PD option.

      


      

        There are no additional requirements for relays.
      


    

      This document introduces one security consideration beyond
      those described in RFC 3315.  A
      malicious DHCPv6 server might cause a client to set its
      SOL_MAX_RT and INF_MAX_RT parameters to an arbitrarily high
      value with the SOL_MAX_RT and INF_MAX_RT options.  Assuming the
      client also receives a response from a valid DHCPv6 server,
      large values for SOL_MAX_RT and INF_MAX_RT will not have any
      effect.
    


    

      IANA is requested to assign an option code from the "DHCP
      Option Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
    


  

  

  
    

    

    
      

      &RFC2119;
      &RFC3315;
    
    
      &RFC3633;
    

  


--------------050303090605000001030301--

From tomasz.mrugalski@gmail.com  Tue Jul  9 05:11: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 1160721F9FF5 for ; Tue,  9 Jul 2013 05:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.082
X-Spam-Level: 
X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYkjRICeRXiV for ; Tue,  9 Jul 2013 05:11:50 -0700 (PDT)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5066221F9FE9 for ; Tue,  9 Jul 2013 05:11:50 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id jm2so2313182bkc.2 for ; Tue, 09 Jul 2013 05:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=v2ap8eyMwHyqV5qSBD4vqp/rFqlBKNIKpPiWWJwNhh4=; b=KCwhnnPSD/TA/vjDYEhoHoiLcS/fgiUPwcEt5D3QM0HWl8l513ua7sTtRNA+eguAnI pjdLKWSF/iE+tK7/sSlF67Vjt1s7zff1nvAE7Dl3YEWTxAUOHwTQbs83VWIc5hlpvwTE 7kcBBnLzn38FE9Y6ruFTjVc1hreOgnVrarWuq7950IHjEIk+4nXFInqUyIvPPDDPHDV1 rycsPEJ+KrCGe9jDRxNmqaoPR/lCHj1TgK0YehMkZHXBMnNgVWA6cP8G7FZvFFhsY29s 20gBN2Khq3UZ1La+PajMnCKcw/VYsfGceRLFi+sf42/acVQEamFIydJQdiQPVqGBi3U3 YU0Q==
X-Received: by 10.204.174.144 with SMTP id t16mr4059998bkz.89.1373371909396; Tue, 09 Jul 2013 05:11:49 -0700 (PDT)
Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id hn4sm5656087bkc.2.2013.07.09.05.11.47 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 05:11:48 -0700 (PDT)
Message-ID: <51DBFE02.4060708@gmail.com>
Date: Tue, 09 Jul 2013 14:11:46 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "dhcwg@ietf.org WG" 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com>
In-Reply-To: <51C32C73.1010203@gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "Bernie Volz \(volz\)" , Ralph Droms , Ted Lemon 
Subject: [dhcwg] WGLC result on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
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, 09 Jul 2013 12:11:51 -0000

On 13-06-20 18:23, Tomek Mrugalski wrote:
> Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
> feels it's ready for work group last call. Please review this draft and
> indicate whether or not you feel it is ready to be published.
>
> ...
> 
> Bernie and I will evaluate consensus after 2013-07-04.
Thank you to all of those that responded with support for moving this
document forward and thank you to Ralph for doing this useful work.

In my and Bernie's opinion this document has consensus to move forward.
There were couple minor issues discussed during WGLC and they will be
resolved in the next revision. As they are sufficiently small, no extra
WGLC is required. We will proceed with shepherding work as soon as
updated version becomes available.

As Bernie and Ralph both work for Cisco, Tomek will be the doc shepherd
for this draft.

Bernie & Tomek

From volz@cisco.com  Tue Jul  9 09:14:04 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 E5D0821F9E1E for ; Tue,  9 Jul 2013 09:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level: 
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plbT8CLDXEhx for ; Tue,  9 Jul 2013 09:13:59 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EA13F21F9E31 for ; Tue,  9 Jul 2013 09:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7872; q=dns/txt; s=iport; t=1373386439; x=1374596039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qSeI5ETyySyMWIm8qtTYTe5duJlGgw1IP/hDNo2Bvn0=; b=XyD54m29XFZUVMa4i57TdZ/LNVamIEN63hqywQ9NtQVANLIQjApLJt5Q dROsrT62J09s1LySj/Hosisn4Q5WargrYjGFABoh8gKa/MoRYK8MiQvp+ yjrE045741ARkVKBmPjtC4YUs8Ir6n6G2XOHdKY0BRwofmrsGLMs+PUiG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlUFAGc23FGtJXG+/2dsb2JhbABagwkywVSBGRZ0giMBAQEDAQEBATc0BgUFCwIBCA4KHhAhBgslAgQOBRuHYgMJBgyxXA2ITQSNAIE0gQQuBQeDCWkDlACBbIFnjCOFJYFYgTmBaAEGGQ
X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="232650339"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jul 2013 16:13:58 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r69GDwFQ030672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 16:13:58 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 11:13:57 -0500
From: "Bernie Volz (volz)" 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfJv3IpMgXmloVk+woYCJQW5N2plchWmV
Date: Tue, 9 Jul 2013 16:13:57 +0000
Message-ID: 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com> <51DABF73.7060300@gmail.com> , <51DBFB65.2000309@gmail.com>
In-Reply-To: <51DBFB65.2000309@gmail.com>
Accept-Language: en-US
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
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 16:14:04 -0000

Regarding:

>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
>> should be constrained to just "receives a Reply message containing a
>> SOL_MAX_RT option"?


Don't we need clients to pick up the values in Advertises as a client that =
only receives NoAddrsAvail (which is usually not followed by Request/Reply)=
 would never pick up the change. And if it gets to Reply stage, it likely d=
oesn't need a new SolMax as it would likely have a lease and stop Solicitin=
g.

Perhaps I am confused as to issue, but I think it has to do with which Adve=
rtise to chose when they are NoAddrsAvail cases. Shouldn't client only use =
SolMax from best (highest pref) Advertise (same as it would have used if it=
 was not a NoAddrsAvail status)?=20

- Bernie (from iPad)

On Jul 9, 2013, at 8:00 AM, "Tomek Mrugalski"  =
wrote:

> On 13-07-08 21:25, Ralph Droms wrote:
>> On Jul 8, 2013, at 9:32 AM 7/8/13, Tomek Mrugalski
>>  wrote:
>>> 1. Clarifying question regarding text:
>>>=20
>>> As a result of receiving this option, the DHCPv6 client MUST NOT
>>> send any Solicit messages more frequently than allowed by the
>>> retransmission mechanism defined in sections 17.1.2 and 14 of RFC
>>> 3315
>>>=20
>>> The (updated) section 17.1.2 says that SOLMAXRT is now 3600
>>> (seconds). Any value received in the option that is smaller than
>>> 3600 will mean that the SOLICIT messages would be sent more
>>> frequently, thus must be ignored. Does it mean that allowed range
>>> of values is 3600 - 2^32-2 ?
>>=20
>> That paragraph isn't well written.  How about:
>>=20
>> If a DHCPv6 client receives a message containing a SOL_MAX_RT option,
>> the client MUST set its internal SOL_MAX_RT parameter to the value
>> contained in the SOL_MAX_RT option.  This value of SOL_MAX_RT is then
>> used by the retransmission mechanism defined in sections 17.1.2 and
>> 14 of RFC 3315 [RFC3315].
>>=20
>> ...which would allow for values of SOL_MAX_RT smaller than the new
>> default of 3600.
> That will work. But there's a potential danger of setting both timers to
> too low value. Rogue server set in IPv4-only network could set both to 1
> and then you'd have a nice packet storm in your network. On the other
> hand I don't think it's a big deal as you can do the same now with T1=3D1
> and very long lifetimes.
>=20
>>> I'm somewhat ok with that, but I would prefer that there would be
>>> an ability to revert to current behaviour, i.e. configure value of
>>> SOLMAXRT option to 120, so old and new clients would behave the
>>> same way.
>>=20
>> Does the new text address this issue by allowing a value of 120 in
>> the SOL_MAX_RT option?
> Yes, thank you.
>=20
>>> In any case, I think the allowed values should be explicitly
>>> specified for both options. I would also consider the upper end of
>>> possible ranges here. 2^32 seconds is around 136 years, so perhaps
>>> limiting the upper value is a good idea as well? Speaking of big
>>> numbers, section 5.6 of 3315 says that 0xffffffff means infinity (I
>>> agree that it is somewhat debatable if that applies to timers, but
>>> it's a matter of interpretation). Is it allowed value here? That
>>> would mean that this draft allows tweaking backoff mechanism to
>>> essentially have no upper threshold. I prefer to not have a
>>> solution that can be told to count to infinity.
>> In my opinion, the additional constraints aren't necessary and it
>> would be better to minimize the changes relative to RFC 3315.
> Ok.
>=20
>> 8.  IANA Considerations
>>=20
>> IANA is requested to assign option codes from the "DHCP Option Codes"
>> Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
> That will work. Thanks.
>=20
>>> 5. The text does not include Client and Server behaviour sections,
>>> as recommended by option-guidelines-12, Section 21. I agree that
>>> this draft is very simple, but it would be good to follow those
>>> recommendations if possible.
>>=20
>> Aw, I was trying to keep this draft as simple as possible.  I'll
>> rewrite the draft if the consensus is that it should follow the
>> guidelines but I'd prefer not to if possible.  Sorry to be lazy (and
>> to resort to a bit of blackmail), but the reality is that rewriting
>> for Client and Server behavior sections is likely to delay the
>> document...
> Nah, it won't delay anything. And I'm blackmail resistant. :) Please see
> proposed XML attached with applied changes 1, 2, 5, 6, and 7. The only
> outstanding issue is whether we want client to use SOL_MAX_RT and
> INF_MAX_RT received in all messages or just REPLY. You may also look at
> new nitpicks 9 and 10 below, if you think they are worth the effort.
>=20
> If we go with REPLY only, we can remove almost all section 6, except
> last NEW paragraph, so the draft becomes even simpler and changes to
> 3315 become smaller.
>=20
>>> 7. Ralph already mentioned his plan to have the name updated to
>>> reflect the addition of INF_MAX_RT.
>>=20
>> "Modifications to Default Values of SOL_MAX_RT and INF_MAX_RT"
> Sounds fine.
>=20
>>> 8. The discussion in Security considerations is not precise.
>>> According to last paragraph of section 4 ("If a DHCPv6 client
>>> receives a message containing a SOL_MAX_RT option, the client MUST
>>> set its internal SOL_MAX_RT parameter to the value contained in the
>>> SOL_MAX_RT option."). Note that this sentence applies to all
>>> received messages, including non-selected Advertises. So whether
>>> the value sent by legitimate or rogue server will be used by the
>>> server, depends on the order of received messages. Also see my
>>> comment #4.
>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
>> should be constrained to just "receives a Reply message containing a
>> SOL_MAX_RT option"?
> That would work fine. One (minor) disadvantage is that with the current
> text you can set up a dummy server that will send out NoAddsAvail and
> longish SOL_MAX_RT/INF_MAX_RT if you don't want to be bothered with
> DHCPv6 in your network and you want to limit the traffic. As I said
> that's really minor disadvantage as the updated clients will go for 1
> packet per hour and the old clients won't use SOL_MAX_RT anyway.
>=20
> I have 2 other minor change proposals:
>=20
> 9. One other thing that occurred to me is possible addition of the
> following text:
>=20
>    Client also MAY include option SOL_MAX_RT in its SOLICIT,
>    REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
>    hint for the server regarding preferred option values.
>=20
> I always liked the idea that DHCP allows negotiations between client and
> server. Sadly, most implementations don't take advantage of such
> capability. But if you don't like this concept, I'm ok with not adding it=
.
>=20
> 10. You mention in 2 places that the options must be sent as top-level
> options, not sub-options. We had a discussion with Ted and Bernie
> regarding vocabulary. Ted prefers sub-options to be used for options
> that use private number spaces (like sub-options in DHCPv4) and use
> "nested" or "encapsulated" for DHCPv6. "Encapsulated" is used in
> RFC3315, but I think it's not a good name as it has overloaded meaning
> (the other is what relays do with client messages). If it was up to me
> to decide, I would go with "nested", but I'm ok with whatever WG decides
> to use. This terminology is discussed in section 9 of option-guidelines.
> I'll be more than happy to update it if needed.
>=20
> Thanks for doing this work.
> Tomek
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

From tomasz.mrugalski@gmail.com  Tue Jul  9 09:57:04 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 0601221F9D11 for ; Tue,  9 Jul 2013 09:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.156
X-Spam-Level: 
X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqP29pW3OgaI for ; Tue,  9 Jul 2013 09:57:03 -0700 (PDT)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6E121F93F8 for ; Tue,  9 Jul 2013 09:57:03 -0700 (PDT)
Received: by mail-bk0-f51.google.com with SMTP id ji1so2464194bkc.38 for ; Tue, 09 Jul 2013 09:57:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=OZ9py7tBUJWkAxVgBjOsbgFdvkTxH9Z+IwvwC0BQ2V0=; b=otubezZSsHMjnGqBJJNTv+UR1x1L18iyxXIpjie4JJlNWyxVeDevlbWjc03OiUV8Pe Q99suVuaXNl0SduQfv6iKTJELa9Tu1rMFU2rYuwjJWGqljJlrN0IlhQvJe1BEy8gvefP 4d+LeZOvocmrm9siikuRcTBGCC+Jsib+dF2iAbcQs1ZBqbkOTpA69ugR6yUx27mRAQt7 sn42yOUjNXeozsZ03DlaOJZvaBz7IpU+r5fAHySTLqkpOYEytG/3Jlo2iiqsOhvSea7R xgDTSiEE/C6cMa1f6J4uzHHKtaWSWBTKyvIFcmeBsB65wz5yWAEVwmYXYdUr7nfLNkq8 D6bg==
X-Received: by 10.204.183.16 with SMTP id ce16mr3729796bkb.172.1373389020996;  Tue, 09 Jul 2013 09:57:00 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id kz11sm6088486bkb.11.2013.07.09.09.56.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 09:56:59 -0700 (PDT)
Message-ID: <51DC40D7.7090104@gmail.com>
Date: Tue, 09 Jul 2013 18:56:55 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Bernie Volz (volz)" 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com> <51DABF73.7060300@gmail.com> , <51DBFB65.2000309@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130709185655297
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 16:57:04 -0000

On 09.07.2013 18:13, Bernie Volz (volz) wrote:
> Regarding:
> 
>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>> option" should be constrained to just "receives a Reply message
>>> containing a SOL_MAX_RT option"?
> 
> Don't we need clients to pick up the values in Advertises as a client
> that only receives NoAddrsAvail (which is usually not followed by
> Request/Reply) would never pick up the change. And if it gets to
> Reply stage, it likely doesn't need a new SolMax as it would likely
> have a lease and stop Soliciting.
I thought about this a bit and I actually prefer Ralph's proposal to use
only REPLY messages. Here's why:
- if you have legacy clients (original 3315), they won't request
SOLMAXRT anyway. You can't do anything about them
- if you have clients that implement solmaxrt, they already start with
3600 value, so the original problem is mostly solved. They will use only
option that is delivered in the sole REPLY (as they do with every other
option).
- You don't have race conditions between advertises from different
servers sending different values in advertise.
- Implementation of the ADVERTISE with NoAddrsAvail would be tricky. The
text would have to say something like "client picks the value from that
ADVERTISE that it would have picked if the ADVERTISE had addresses".

> Perhaps I am confused as to issue, but I think it has to do with
> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
> client only use SolMax from best (highest pref) Advertise (same as it
> would have used if it was not a NoAddrsAvail status)?
It's more complicated than that. Highest preference is not the only
indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
less-preferred server if that server has a better set of advertised
parameters, such as the available addresses advertised in IAs.").

I'm definitely with Ralph here - it is much cleaner to stick to REPLY
only. Speaking with my chair hat off and my implementor hat on: The
easiest to implement is this: the option will be requested in SOLICIT
and REQUEST, but only the value from REPLY will actually be consumed.
(that how every other option is used anyway).

Tomek

From volz@cisco.com  Tue Jul  9 10:08:53 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 9DE0E21F9EAA for ; Tue,  9 Jul 2013 10:08:48 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq45kuhELIdg for ; Tue,  9 Jul 2013 10:08:43 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43021F9EA2 for ; Tue,  9 Jul 2013 10:08:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3584; q=dns/txt; s=iport; t=1373389723; x=1374599323; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WskIDQ9QPvGujnQ9L84iOwlSPaOZcIY7TkvWTXYfYRY=; b=CcL7k+pxz+w8afAY8CiU2Sbg+9YPNdHjrm7BH9G7hjJE22MsQ+KXbHhr muPliby3dVVBHiIlKrseHp3/lOVbVKlH+ryu4v5PquXavevZa+c+BmK1O Cu/C6/2AUjE1gUe9UK9xQc5XS3JIQ79HhxfnhPesDxlcc4vaKA0Tys95L g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlUFAAhD3FGtJV2d/2dsb2JhbABagwkyTcEUgRkWdIIjAQEBBAEBATc0BgUSAQgOCgoUMQYLJQIEDgUIh3UDDwyxXw2ITQSNAII6MQeDCWkDlWyOCoUlgViBOYIo
X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="229689013"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 09 Jul 2013 17:08:42 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r69H8gRp029466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 17:08:42 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 12:08:42 -0500
From: "Bernie Volz (volz)" 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfJv3IpMgXmloVk+woYCJQW5N2plchWmVgABf0oD//8A4AA==
Date: Tue, 9 Jul 2013 17:08:42 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185D95B1@xmb-rcd-x04.cisco.com>
In-Reply-To: <51DC40D7.7090104@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [161.44.65.145]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 17:08:53 -0000

I'm OK with that as I buy your analysis. And it would be tricky otherwise.

What about Information-Request and Reply to that? Can those include
SOLMAX? (Or just the Info Max).

   A DHCPv6 client MUST include the SOL_MAX_RT option code in an Option
   Request option [RFC3315] in any message it sends.

   The DHCPv6 server MAY include the SOL_MAX_RT option in any response
   it sends to a client that has included the SOL_MAX_RT option code in
   an Option Request option.



BTW: Perhaps already a known issue, but isn't the text in Section 5 wrong:

   5. INF_MAX_RT option

   A DHCPv6 server sends the INF_MAX_RT option to a client to override
   the default value of INF_MAX_RT.  The value of INF_MAX_RT in the
   option replaces the default value defined in Section 3.  One use for
   the INF_MAX_RT option is to set a longer value for INF_MAX_RT, which
   reduces the Solicit traffic from a client that has not received a
               ^^^^^^^ Information-Request
   response to its Solicit messages.

                   ^^^^^^^ Information-Request


- Bernie

On 7/9/13 12:56 PM, "Tomek Mrugalski"  wrote:

>On 09.07.2013 18:13, Bernie Volz (volz) wrote:
>> Regarding:
>>=20
>>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>>> option" should be constrained to just "receives a Reply message
>>>> containing a SOL_MAX_RT option"?
>>=20
>> Don't we need clients to pick up the values in Advertises as a client
>> that only receives NoAddrsAvail (which is usually not followed by
>> Request/Reply) would never pick up the change. And if it gets to
>> Reply stage, it likely doesn't need a new SolMax as it would likely
>> have a lease and stop Soliciting.
>I thought about this a bit and I actually prefer Ralph's proposal to use
>only REPLY messages. Here's why:
>- if you have legacy clients (original 3315), they won't request
>SOLMAXRT anyway. You can't do anything about them
>- if you have clients that implement solmaxrt, they already start with
>3600 value, so the original problem is mostly solved. They will use only
>option that is delivered in the sole REPLY (as they do with every other
>option).
>- You don't have race conditions between advertises from different
>servers sending different values in advertise.
>- Implementation of the ADVERTISE with NoAddrsAvail would be tricky. The
>text would have to say something like "client picks the value from that
>ADVERTISE that it would have picked if the ADVERTISE had addresses".
>
>> Perhaps I am confused as to issue, but I think it has to do with
>> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
>> client only use SolMax from best (highest pref) Advertise (same as it
>> would have used if it was not a NoAddrsAvail status)?
>It's more complicated than that. Highest preference is not the only
>indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
>less-preferred server if that server has a better set of advertised
>parameters, such as the available addresses advertised in IAs.").
>
>I'm definitely with Ralph here - it is much cleaner to stick to REPLY
>only. Speaking with my chair hat off and my implementor hat on: The
>easiest to implement is this: the option will be requested in SOLICIT
>and REQUEST, but only the value from REPLY will actually be consumed.
>(that how every other option is used anyway).
>
>Tomek
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From Ted.Lemon@nominum.com  Tue Jul  9 11:42: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 6EED921F9D8A for ; Tue,  9 Jul 2013 11:42:13 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBL6Q0iNhNS6 for ; Tue,  9 Jul 2013 11:42:06 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A8FC621F9D8D for ; Tue,  9 Jul 2013 11:42:06 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUdxZfoeKOkjgvPHWkGcNN/WAOg17zT8D@postini.com; Tue, 09 Jul 2013 11:42:06 PDT
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 DDAD61B823F for ; Tue,  9 Jul 2013 11:42:05 -0700 (PDT)
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 C061E190052; Tue,  9 Jul 2013 11:42:05 -0700 (PDT) (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; Tue, 9 Jul 2013 11:42:06 -0700
From: Ted Lemon 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfJv1kwkx45UHdUONYvWEOf3i5Zlc+sGAgAAMAYCAAB1hAA==
Date: Tue, 9 Jul 2013 18:42:05 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520691B@mbx-01.win.nominum.com>
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com> <51DABF73.7060300@gmail.com> , <51DBFB65.2000309@gmail.com>  <51DC40D7.7090104@gmail.com>
In-Reply-To: <51DC40D7.7090104@gmail.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
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 18:42:13 -0000

On Jul 9, 2013, at 12:56 PM, Tomek Mrugalski  w=
rote:
> - You don't have race conditions between advertises from different
> servers sending different values in advertise.

If there are multiple servers sending different values, it seems likely tha=
t something is broken.


From tomasz.mrugalski@gmail.com  Tue Jul  9 14:25:21 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 A897E21F8BE6 for ; Tue,  9 Jul 2013 14:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level: 
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.388,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFhtvNDhGq7C for ; Tue,  9 Jul 2013 14:25:19 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD721F881F for ; Tue,  9 Jul 2013 14:25:18 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id d7so2565166bkh.25 for ; Tue, 09 Jul 2013 14:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=EX8AQfu1KjAmpZKMMudVwfsoYEQW1ZwoEVSNM0uwAI8=; b=dVFRQO0MgW+FTYFo1MqTAso+d0u6wAQNFagOOb2bWkvg021axO61WJ8JEsvWmYQrtL cfMSsFEY976WHxCy5HknpHOZNWzrYz2HtGjcOCc85lE+age9CSRiskVqysQL5/vOzEyf uYsp/iK6nxsxGPW0cHxP5Ma0nFzyNRYB5e2t23qQWRztzN857Pr7tWC4VBPpAxM8uQKr CgVkAZ24NWDGdx9TihVKn6uEldSR7PIlTF0AiSDreQFU229YaAnmdC4WdowujqCzQ4KC 6sNSSpssjxl9apemGAwJhUwoJD50WtBXF9E+76ORB4MXm3LCk25K/a6s9aoCR662GL6d dR9A==
X-Received: by 10.204.239.132 with SMTP id kw4mr4461604bkb.39.1373405117379; Tue, 09 Jul 2013 14:25:17 -0700 (PDT)
Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id m6sm6284571bki.7.2013.07.09.14.25.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 14:25:16 -0700 (PDT)
Message-ID: <51DC7FB9.6090300@gmail.com>
Date: Tue, 09 Jul 2013 23:25:13 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ted Lemon 
References: <3135C2851EB6764BACEF35D8B495596806E7DAB304@MOPESMBX01.eu.thmulti.com> <51C31065.8040804@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751E2D82@mbx-01.win.nominum.com>  <51C32C73.1010203@gmail.com> <51DABF73.7060300@gmail.com> , <51DBFB65.2000309@gmail.com>  <51DC40D7.7090104@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077520691B@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520691B@mbx-01.win.nominum.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 21:25:22 -0000

On 13-07-09 20:42, Ted Lemon wrote:
> On Jul 9, 2013, at 12:56 PM, Tomek Mrugalski  wrote:
>> - You don't have race conditions between advertises from different
>> servers sending different values in advertise.
> 
> If there are multiple servers sending different values, it seems likely that something is broken.
Yes, I stated that in previous mail. That is either a configuration
error or a rogue server. Nevertheless it would be good if client could
handle such situation gently. Ralph's proposal to use only options from
REPLY does that.



From john_brzozowski@cable.comcast.com  Tue Jul  9 15:50: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 3277D21F8613 for ; Tue,  9 Jul 2013 15:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.216
X-Spam-Level: 
X-Spam-Status: No, score=-104.216 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkloQXfnpTEh for ; Tue,  9 Jul 2013 15:50:04 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7E11E8198 for ; Tue,  9 Jul 2013 15:50:01 -0700 (PDT)
Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.81638798; Tue, 09 Jul 2013 16:48:03 -0600
Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 9 Jul 2013 18:49:50 -0400
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Tue, 9 Jul 2013 18:48:48 -0400
From: "Brzozowski, John" 
To: "Bernie Volz (volz)" , Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfJvsnUZzNLAd0UOoNaBD0vF7Q5lcyHeAgAArvQA=
Date: Tue, 9 Jul 2013 22:48:46 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [68.87.16.246]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2A342FE25FE5A847A51F05E37CBADF45@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 22:50:10 -0000

Bernie I think you are correct as this is one the original scenarios that
resulted in this draft.  Thanks for catching this.


John
-----Original Message-----
From: Bernie Volz 
Date: Tuesday, July 9, 2013 12:13 PM
To: Tomasz Mrugalski 
Cc: dhc WG , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>Regarding:
>
>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
>>> should be constrained to just "receives a Reply message containing a
>>> SOL_MAX_RT option"?
>
>
>Don't we need clients to pick up the values in Advertises as a client
>that only receives NoAddrsAvail (which is usually not followed by
>Request/Reply) would never pick up the change. And if it gets to Reply
>stage, it likely doesn't need a new SolMax as it would likely have a
>lease and stop Soliciting.
>
>Perhaps I am confused as to issue, but I think it has to do with which
>Advertise to chose when they are NoAddrsAvail cases. Shouldn't client
>only use SolMax from best (highest pref) Advertise (same as it would have
>used if it was not a NoAddrsAvail status)?
>
>- Bernie (from iPad)
>
>On Jul 9, 2013, at 8:00 AM, "Tomek Mrugalski"
> wrote:
>
>> On 13-07-08 21:25, Ralph Droms wrote:
>>> On Jul 8, 2013, at 9:32 AM 7/8/13, Tomek Mrugalski
>>>  wrote:
>>>> 1. Clarifying question regarding text:
>>>>=20
>>>> As a result of receiving this option, the DHCPv6 client MUST NOT
>>>> send any Solicit messages more frequently than allowed by the
>>>> retransmission mechanism defined in sections 17.1.2 and 14 of RFC
>>>> 3315
>>>>=20
>>>> The (updated) section 17.1.2 says that SOLMAXRT is now 3600
>>>> (seconds). Any value received in the option that is smaller than
>>>> 3600 will mean that the SOLICIT messages would be sent more
>>>> frequently, thus must be ignored. Does it mean that allowed range
>>>> of values is 3600 - 2^32-2 ?
>>>=20
>>> That paragraph isn't well written.  How about:
>>>=20
>>> If a DHCPv6 client receives a message containing a SOL_MAX_RT option,
>>> the client MUST set its internal SOL_MAX_RT parameter to the value
>>> contained in the SOL_MAX_RT option.  This value of SOL_MAX_RT is then
>>> used by the retransmission mechanism defined in sections 17.1.2 and
>>> 14 of RFC 3315 [RFC3315].
>>>=20
>>> ...which would allow for values of SOL_MAX_RT smaller than the new
>>> default of 3600.
>> That will work. But there's a potential danger of setting both timers to
>> too low value. Rogue server set in IPv4-only network could set both to 1
>> and then you'd have a nice packet storm in your network. On the other
>> hand I don't think it's a big deal as you can do the same now with T1=3D=
1
>> and very long lifetimes.
>>=20
>>>> I'm somewhat ok with that, but I would prefer that there would be
>>>> an ability to revert to current behaviour, i.e. configure value of
>>>> SOLMAXRT option to 120, so old and new clients would behave the
>>>> same way.
>>>=20
>>> Does the new text address this issue by allowing a value of 120 in
>>> the SOL_MAX_RT option?
>> Yes, thank you.
>>=20
>>>> In any case, I think the allowed values should be explicitly
>>>> specified for both options. I would also consider the upper end of
>>>> possible ranges here. 2^32 seconds is around 136 years, so perhaps
>>>> limiting the upper value is a good idea as well? Speaking of big
>>>> numbers, section 5.6 of 3315 says that 0xffffffff means infinity (I
>>>> agree that it is somewhat debatable if that applies to timers, but
>>>> it's a matter of interpretation). Is it allowed value here? That
>>>> would mean that this draft allows tweaking backoff mechanism to
>>>> essentially have no upper threshold. I prefer to not have a
>>>> solution that can be told to count to infinity.
>>> In my opinion, the additional constraints aren't necessary and it
>>> would be better to minimize the changes relative to RFC 3315.
>> Ok.
>>=20
>>> 8.  IANA Considerations
>>>=20
>>> IANA is requested to assign option codes from the "DHCP Option Codes"
>>> Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
>> That will work. Thanks.
>>=20
>>>> 5. The text does not include Client and Server behaviour sections,
>>>> as recommended by option-guidelines-12, Section 21. I agree that
>>>> this draft is very simple, but it would be good to follow those
>>>> recommendations if possible.
>>>=20
>>> Aw, I was trying to keep this draft as simple as possible.  I'll
>>> rewrite the draft if the consensus is that it should follow the
>>> guidelines but I'd prefer not to if possible.  Sorry to be lazy (and
>>> to resort to a bit of blackmail), but the reality is that rewriting
>>> for Client and Server behavior sections is likely to delay the
>>> document...
>> Nah, it won't delay anything. And I'm blackmail resistant. :) Please see
>> proposed XML attached with applied changes 1, 2, 5, 6, and 7. The only
>> outstanding issue is whether we want client to use SOL_MAX_RT and
>> INF_MAX_RT received in all messages or just REPLY. You may also look at
>> new nitpicks 9 and 10 below, if you think they are worth the effort.
>>=20
>> If we go with REPLY only, we can remove almost all section 6, except
>> last NEW paragraph, so the draft becomes even simpler and changes to
>> 3315 become smaller.
>>=20
>>>> 7. Ralph already mentioned his plan to have the name updated to
>>>> reflect the addition of INF_MAX_RT.
>>>=20
>>> "Modifications to Default Values of SOL_MAX_RT and INF_MAX_RT"
>> Sounds fine.
>>=20
>>>> 8. The discussion in Security considerations is not precise.
>>>> According to last paragraph of section 4 ("If a DHCPv6 client
>>>> receives a message containing a SOL_MAX_RT option, the client MUST
>>>> set its internal SOL_MAX_RT parameter to the value contained in the
>>>> SOL_MAX_RT option."). Note that this sentence applies to all
>>>> received messages, including non-selected Advertises. So whether
>>>> the value sent by legitimate or rogue server will be used by the
>>>> server, depends on the order of received messages. Also see my
>>>> comment #4.
>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT option"
>>> should be constrained to just "receives a Reply message containing a
>>> SOL_MAX_RT option"?
>> That would work fine. One (minor) disadvantage is that with the current
>> text you can set up a dummy server that will send out NoAddsAvail and
>> longish SOL_MAX_RT/INF_MAX_RT if you don't want to be bothered with
>> DHCPv6 in your network and you want to limit the traffic. As I said
>> that's really minor disadvantage as the updated clients will go for 1
>> packet per hour and the old clients won't use SOL_MAX_RT anyway.
>>=20
>> I have 2 other minor change proposals:
>>=20
>> 9. One other thing that occurred to me is possible addition of the
>> following text:
>>=20
>>    Client also MAY include option SOL_MAX_RT in its SOLICIT,
>>    REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
>>    hint for the server regarding preferred option values.
>>=20
>> I always liked the idea that DHCP allows negotiations between client and
>> server. Sadly, most implementations don't take advantage of such
>> capability. But if you don't like this concept, I'm ok with not adding
>>it.
>>=20
>> 10. You mention in 2 places that the options must be sent as top-level
>> options, not sub-options. We had a discussion with Ted and Bernie
>> regarding vocabulary. Ted prefers sub-options to be used for options
>> that use private number spaces (like sub-options in DHCPv4) and use
>> "nested" or "encapsulated" for DHCPv6. "Encapsulated" is used in
>> RFC3315, but I think it's not a good name as it has overloaded meaning
>> (the other is what relays do with client messages). If it was up to me
>> to decide, I would go with "nested", but I'm ok with whatever WG decides
>> to use. This terminology is discussed in section 9 of option-guidelines.
>> I'll be more than happy to update it if needed.
>>=20
>> Thanks for doing this work.
>> Tomek
>> 
>> _______________________________________________
>> 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 john_brzozowski@cable.comcast.com  Tue Jul  9 16:34: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 5B6EB11E80D3 for ; Tue,  9 Jul 2013 16:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.343
X-Spam-Level: 
X-Spam-Status: No, score=-104.343 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDJWgCmb6Ufy for ; Tue,  9 Jul 2013 16:34:34 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id D32E711E80C5 for ; Tue,  9 Jul 2013 16:34:33 -0700 (PDT)
Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.81643299; Tue, 09 Jul 2013 17:32:50 -0600
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Tue, 9 Jul 2013 19:34:28 -0400
From: "Brzozowski, John" 
To: Tomek Mrugalski , "Bernie Volz (volz)" 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfJvsnUZzNLAd0UOoNaBD0vF7Q5lcyHeAgAAMAYCAACiPgA==
Date: Tue, 9 Jul 2013 23:34:28 +0000
Message-ID: 
In-Reply-To: <51DC40D7.7090104@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [68.87.16.247]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 09 Jul 2013 23:34:39 -0000

See below.


-----Original Message-----
From: Tomasz Mrugalski 
Date: Tuesday, July 9, 2013 12:56 PM
To: Bernie Volz 
Cc: dhc WG , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>On 09.07.2013 18:13, Bernie Volz (volz) wrote:
>> Regarding:
>>=20
>>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>>> option" should be constrained to just "receives a Reply message
>>>> containing a SOL_MAX_RT option"?
>>=20
>> Don't we need clients to pick up the values in Advertises as a client
>> that only receives NoAddrsAvail (which is usually not followed by
>> Request/Reply) would never pick up the change. And if it gets to
>> Reply stage, it likely doesn't need a new SolMax as it would likely
>> have a lease and stop Soliciting.
>I thought about this a bit and I actually prefer Ralph's proposal to use
>only REPLY messages. Here's why:
>- if you have legacy clients (original 3315), they won't request
>SOLMAXRT anyway. You can't do anything about them
>- if you have clients that implement solmaxrt, they already start with
>3600 value, so the original problem is mostly solved. They will use only
>option that is delivered in the sole REPLY (as they do with every other
>option).
>- You don't have race conditions between advertises from different
>servers sending different values in advertise.
>- Implementation of the ADVERTISE with NoAddrsAvail would be tricky. The
>text would have to say something like "client picks the value from that
>ADVERTISE that it would have picked if the ADVERTISE had addresses".
[jjmb] these are good points and I do not mean to seem like I am bouncing
back and forth.  I suppose what Tomasz is suggesting would be a reasonable
compromise.

>
>> Perhaps I am confused as to issue, but I think it has to do with
>> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
>> client only use SolMax from best (highest pref) Advertise (same as it
>> would have used if it was not a NoAddrsAvail status)?
>It's more complicated than that. Highest preference is not the only
>indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
>less-preferred server if that server has a better set of advertised
>parameters, such as the available addresses advertised in IAs.").
>
>I'm definitely with Ralph here - it is much cleaner to stick to REPLY
>only. Speaking with my chair hat off and my implementor hat on: The
>easiest to implement is this: the option will be requested in SOLICIT
>and REQUEST, but only the value from REPLY will actually be consumed.
>(that how every other option is used anyway).
>
>Tomek
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From gvithal@gmail.com  Wed Jul 10 04:16: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 C919A21F9E7D for ; Wed, 10 Jul 2013 04:16:38 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYL-ET+Dmhxk for ; Wed, 10 Jul 2013 04:16:38 -0700 (PDT)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5519121F9E7B for ; Wed, 10 Jul 2013 04:16:38 -0700 (PDT)
Received: by mail-ve0-f181.google.com with SMTP id db10so5662386veb.12 for ; Wed, 10 Jul 2013 04:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yIAB49kSgE2n5m6l/0/KZHUw9D5iwLqM4Xjz5/8Glfo=; b=sRBnovILTtGFwBitt/C+G6z4lM4JTS4qMrALYySJScKC3xXmuRxNDJ9Q78Y72muzUK k7sOS8xbIbke0hDRjUyld+IPYOtAJ/1SseA/W4LjcwuWDAupawCRbwTwDdAhSEf9drIl APIXulAVJFH5+3L9NNgJL/jheeBGJl4jzHlpQV78EfIecoxImqfWQWhUhZ3TWEf7dboZ vPE1VnvcO6zNnN70IYoUm0lFpJstczX9QukyhNERjeg7VNt6uzPERkSI5WVSuqSaviZc 8S7dZwZFCK1YTh8Cyh/wwgcHgA/O0poTmMs1bsM1kKYOpFviaSwxotdbzv/m2S38orKX IaJA==
MIME-Version: 1.0
X-Received: by 10.52.248.166 with SMTP id yn6mr15577238vdc.41.1373454997814; Wed, 10 Jul 2013 04:16:37 -0700 (PDT)
Received: by 10.58.146.36 with HTTP; Wed, 10 Jul 2013 04:16:37 -0700 (PDT)
Date: Wed, 10 Jul 2013 16:46:37 +0530
Message-ID: 
From: "gvithal ." 
To: "" 
Content-Type: multipart/alternative; boundary=089e0160a43442caf004e12669ab
Subject: [dhcwg] Source IP address and Server identifier
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, 10 Jul 2013 11:16:38 -0000

--089e0160a43442caf004e12669ab
Content-Type: text/plain; charset=ISO-8859-1

Is it valid scenario for server identifier in the DHCP ACK to be a
different IP address then the source IP in IP header.
What is the expected client behaviour in this case.
There does not seem to be any text in RFC 2131 related to this scenario.

Thanks,
Prasad

--089e0160a43442caf004e12669ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Is it valid scenario for server identifier in the DHCP ACK to be a differ=
ent IP address then the source IP in IP header.

What is the expected client behaviour in this case.
There does not seem to be any text=
 in RFC 2131 related to this scenario.


Thanks=
,
Prasad


--089e0160a43442caf004e12669ab--

From volz@cisco.com  Wed Jul 10 06:00: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 11DD411E8123 for ; Wed, 10 Jul 2013 06:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Level: 
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o150t1s6-Eo for ; Wed, 10 Jul 2013 06:00:00 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 30F2611E8170 for ; Wed, 10 Jul 2013 06:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1373461200; x=1374670800; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xjb7BNNrB/ULQKCoKuDZ5HWXBQMAGOkjXXJKC+mcGvc=; b=RN4CT6zF5o0Np1IHh/RRNtXl6gTxX1azbuD737GvhNY47+zj7dV6mFkk B7oeqVdPwrUvnlzxXCX6z5bo7tVG6eNMU1SNXg1Q0NhXKE8ZEVbuO0Het 8jFV8uo0MbV02LeY72hPkEBr7sD+N0q1LcF4yIhZz30CR2kdYpntMZvNF U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAE1Z3VGtJXG9/2dsb2JhbABagkVEMsFdgQ8WdIIkAQEEAQEBawsQAgEIBDsHIQYLFBECBA4Fh30DDwyxCg2ITQSMeIJnBAeDCWwDlW+BaIwkhSaDEQ
X-IronPort-AV: E=Sophos;i="4.87,1036,1363132800";  d="scan'208,217";a="233049052"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jul 2013 12:59:23 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6ACxNLR020969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 12:59:23 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 07:59:23 -0500
From: "Bernie Volz (volz)" 
To: "gvithal ." 
Thread-Topic: [dhcwg] Source IP address and Server identifier
Thread-Index: AQHOfV73gj+wwJ9Xs0mf7y9XCRywwpld39qK
Date: Wed, 10 Jul 2013 12:59:22 +0000
Message-ID: <8FE2A923-E611-454A-93D0-85B2DC7021B3@cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_8FE2A923E611454A93D085B2DC7021B3ciscocom_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [dhcwg] Source IP address and Server identifier
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, 10 Jul 2013 13:00:05 -0000

--_000_8FE2A923E611454A93D085B2DC7021B3ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes. The packet could have been relayed which means ip header source is rel=
ay, not server.

V4 clients (and servers) don't look at ip header fields.

- Bernie (from iPad)

On Jul 10, 2013, at 7:16 AM, "gvithal ." > wrote:

Is it valid scenario for server identifier in the DHCP ACK to be a differen=
t IP address then the source IP in IP header.
What is the expected client behaviour in this case.
There does not seem to be any text in RFC 2131 related to this scenario.

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

--_000_8FE2A923E611454A93D085B2DC7021B3ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Yes. The packet could have been relayed which means ip header source i=
s relay, not server.







V4 clients (and servers) don't look at ip header fields.



- Bernie (from iPad)




On Jul 10, 2013, at 7:16 AM, "gvithal ." <gvithal@gmail.com> wrote:










Is it valid scenario for server identifier in the DHCP ACK to be a differ=
ent IP address then the source IP in IP header.

What is the expe=
cted client behaviour in this case.


There does not s=
eem to be any text in RFC 2131 related to this scenario.







Thanks,


Prasad










_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg








--_000_8FE2A923E611454A93D085B2DC7021B3ciscocom_--

From Ted.Lemon@nominum.com  Wed Jul 10 07:46: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 AFC8711E80E1 for ; Wed, 10 Jul 2013 07:46:51 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vJD+bCTAe91 for ; Wed, 10 Jul 2013 07:46:45 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 93FCD21F9E0A for ; Wed, 10 Jul 2013 07:46:40 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUd1zw7clA2gZUldgzCII1HxXy7t9gy4Q@postini.com; Wed, 10 Jul 2013 07:46:40 PDT
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 22C1C1B819E for ; Wed, 10 Jul 2013 07:46:27 -0700 (PDT)
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 1AE40190052; Wed, 10 Jul 2013 07:46:27 -0700 (PDT) (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, 10 Jul 2013 07:46:27 -0700
From: Ted Lemon 
To: "gvithal ." 
Thread-Topic: [dhcwg] Source IP address and Server identifier
Thread-Index: AQHOfV71b/+4JYazNUCDI3ZdPhWedZlecxwA
Date: Wed, 10 Jul 2013 14:46:26 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752085D8@mbx-01.win.nominum.com>
References: 
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: <04DEE8AAA8A511499366CB932CA96574@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [dhcwg] Source IP address and Server identifier
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, 10 Jul 2013 14:46:51 -0000

On Jul 10, 2013, at 7:16 AM, "gvithal ."  wrote:
> Is it valid scenario for server identifier in the DHCP ACK to be a differ=
ent IP address then the source IP in IP header.
> What is the expected client behaviour in this case.

The only requirement is that the server identifier be an IP address on whic=
h the DHCP server is reachable.


From jiangsheng@huawei.com  Wed Jul 10 18:18:41 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 40AA711E80A2 for ; Wed, 10 Jul 2013 18:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJrHYDWq-lbV for ; Wed, 10 Jul 2013 18:18:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C628221F9AC1 for ; Wed, 10 Jul 2013 18:18:31 -0700 (PDT)
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 AUX09456; Thu, 11 Jul 2013 01:18:30 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 02:18:09 +0100
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 02:18:29 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 09:18:24 +0800
From: Sheng Jiang 
To: Ted Lemon , "gvithal ." 
Thread-Topic: [dhcwg] Source IP address and Server identifier
Thread-Index: AQHOfV8I1DfNRIhmbkKx6r6m028pnpldd6cAgAE2T+A=
Date: Thu, 11 Jul 2013 01:18:23 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACAB936@nkgeml512-mbx.china.huawei.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752085D8@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307752085D8@mbx-01.win.nominum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "" 
Subject: Re: [dhcwg] Source IP address and Server identifier
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, 11 Jul 2013 01:18:41 -0000

SWYgdGhlcmUgd2FzIHJlcXVpcmVtZW50cywgYSByZWFzb25hYmxlIHNvbHV0aW9uIGNvdWxkIGJl
IGEgbmV3IHR5cGUgb2YgRFVJRCwgd2hpY2ggY2FycmllcyBzZXJ2ZXIncyBJUCBhZGRyZXNzIGlu
IHRoZSByZWxheS1yZXBseSBtZXNzYWdlLg0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgVGVkIExlbW9uDQo+U2VudDogV2VkbmVzZGF5
LCBKdWx5IDEwLCAyMDEzIDEwOjQ2IFBNDQo+VG86IGd2aXRoYWwgLg0KPkNjOiA8ZGhjd2dAaWV0
Zi5vcmc+DQo+U3ViamVjdDogUmU6IFtkaGN3Z10gU291cmNlIElQIGFkZHJlc3MgYW5kIFNlcnZl
ciBpZGVudGlmaWVyDQo+DQo+T24gSnVsIDEwLCAyMDEzLCBhdCA3OjE2IEFNLCAiZ3ZpdGhhbCAu
IiA8Z3ZpdGhhbEBnbWFpbC5jb20+IHdyb3RlOg0KPj4gSXMgaXQgdmFsaWQgc2NlbmFyaW8gZm9y
IHNlcnZlciBpZGVudGlmaWVyIGluIHRoZSBESENQIEFDSyB0byBiZSBhIGRpZmZlcmVudCBJUA0K
PmFkZHJlc3MgdGhlbiB0aGUgc291cmNlIElQIGluIElQIGhlYWRlci4NCj4+IFdoYXQgaXMgdGhl
IGV4cGVjdGVkIGNsaWVudCBiZWhhdmlvdXIgaW4gdGhpcyBjYXNlLg0KPg0KPlRoZSBvbmx5IHJl
cXVpcmVtZW50IGlzIHRoYXQgdGhlIHNlcnZlciBpZGVudGlmaWVyIGJlIGFuIElQIGFkZHJlc3Mg
b24gd2hpY2gNCj50aGUgREhDUCBzZXJ2ZXIgaXMgcmVhY2hhYmxlLg0KPg0KPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0
DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2RoY3dnDQo=

From Ted.Lemon@nominum.com  Wed Jul 10 18:44:29 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 D374111E80EE for ; Wed, 10 Jul 2013 18:44:28 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y715u6-2XGrK for ; Wed, 10 Jul 2013 18:44:20 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id D936421F9C29 for ; Wed, 10 Jul 2013 18:44:19 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUd4N8seXh2rvNWZ32em0+jieLxaWLu88@postini.com; Wed, 10 Jul 2013 18:44:19 PDT
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 7EBE91B824A for ; Wed, 10 Jul 2013 18:44:18 -0700 (PDT)
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 64B2B190052; Wed, 10 Jul 2013 18:44:18 -0700 (PDT) (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, 10 Jul 2013 18:44:18 -0700
From: Ted Lemon 
To: Sheng Jiang 
Thread-Topic: [dhcwg] Source IP address and Server identifier
Thread-Index: AQHOfV71b/+4JYazNUCDI3ZdPhWedZlecxwAgACwkYCAAAc7AA==
Date: Thu, 11 Jul 2013 01:44:16 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630775209B3F@mbx-01.win.nominum.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752085D8@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923ACAB936@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923ACAB936@nkgeml512-mbx.china.huawei.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: <7AB12BCEB87369449607641B92B171CC@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [dhcwg] Source IP address and Server identifier
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, 11 Jul 2013 01:44:29 -0000

On Jul 10, 2013, at 9:18 PM, Sheng Jiang  wrote:
> If there was requirements, a reasonable solution could be a new type of D=
UID, which carries server's IP address in the relay-reply message.

Hm, I assumed he was talking about DHCPv4...


From rdroms.ietf@gmail.com  Thu Jul 11 08:47:01 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 BCBA521F9EED for ; Thu, 11 Jul 2013 08:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.66
X-Spam-Level: 
X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+e3tCl3cRKL for ; Thu, 11 Jul 2013 08:46:58 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 031E721F9E36 for ; Thu, 11 Jul 2013 08:46:56 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id hu16so7696376qab.8 for ; Thu, 11 Jul 2013 08:46:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=/BR2LsgUUs8OGtUG9UiWD4Mf1DjIXl781BiKaViQ7i4=; b=MLRScUAVf7E9+N/D0s2JQSXbbkN5t+cjTtLlHXTTpJHV3M86QD1qs0BLGINhC4RYpJ fEIJImIvmn2aMOsi5cQYEBv1lAGVlCKKRIsl8q5OlN+qbUlVUQhoyJdJeliCjHBIlqYO ErLCLCTaKvq7JBl9m24KI25xsO2OoM7/hkfDoYyMtznS1naOsYmJ4KTwCFjd2DXdXod1 aWOVbQ8ZCI3tleCCeSmYQkGPgiYm1GF5U8quMFaBNnhVbDlQwXirWyn7PM8RavDkdLer gn0X19oQ/xMWvIgfM4EbgK0iGtRFGlu7bxigS4uLw/M/xrJu+GgVjDHS0ySIjplK9jSC hLfg==
X-Received: by 10.49.62.33 with SMTP id v1mr30413457qer.53.1373557616382; Thu, 11 Jul 2013 08:46:56 -0700 (PDT)
Received: from rtp-rdroms-8919.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id a8sm30266740qae.11.2013.07.11.08.46.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 08:46:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: 
Date: Thu, 11 Jul 2013 11:46:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "dhcwg@ietf.org WG" 
X-Mailer: Apple Mail (2.1508)
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 11 Jul 2013 15:47:01 -0000

Please review -02 (thanks, Tomek!) and post any comments; "looks OK" is =
a fine comment.  If the chairs will determine consensus, I'll publish =
rev -02 tomorrow (Friday) as the final candidate for submission to the =
IESG.

- Ralph

On Jul 9, 2013, at 7:34 PM 7/9/13, "Brzozowski, John" =
 wrote:

> See below.
>=20
>=20
> -----Original Message-----
> From: Tomasz Mrugalski 
> Date: Tuesday, July 9, 2013 12:56 PM
> To: Bernie Volz 
> Cc: dhc WG , Ralph Droms 
> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 =
-
> respond by July 4
>=20
>> On 09.07.2013 18:13, Bernie Volz (volz) wrote:
>>> Regarding:
>>>=20
>>>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>>>> option" should be constrained to just "receives a Reply message
>>>>> containing a SOL_MAX_RT option"?
>>>=20
>>> Don't we need clients to pick up the values in Advertises as a =
client
>>> that only receives NoAddrsAvail (which is usually not followed by
>>> Request/Reply) would never pick up the change. And if it gets to
>>> Reply stage, it likely doesn't need a new SolMax as it would likely
>>> have a lease and stop Soliciting.
>> I thought about this a bit and I actually prefer Ralph's proposal to =
use
>> only REPLY messages. Here's why:
>> - if you have legacy clients (original 3315), they won't request
>> SOLMAXRT anyway. You can't do anything about them
>> - if you have clients that implement solmaxrt, they already start =
with
>> 3600 value, so the original problem is mostly solved. They will use =
only
>> option that is delivered in the sole REPLY (as they do with every =
other
>> option).
>> - You don't have race conditions between advertises from different
>> servers sending different values in advertise.
>> - Implementation of the ADVERTISE with NoAddrsAvail would be tricky. =
The
>> text would have to say something like "client picks the value from =
that
>> ADVERTISE that it would have picked if the ADVERTISE had addresses".
> [jjmb] these are good points and I do not mean to seem like I am =
bouncing
> back and forth.  I suppose what Tomasz is suggesting would be a =
reasonable
> compromise.
>=20
>>=20
>>> Perhaps I am confused as to issue, but I think it has to do with
>>> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
>>> client only use SolMax from best (highest pref) Advertise (same as =
it
>>> would have used if it was not a NoAddrsAvail status)?
>> It's more complicated than that. Highest preference is not the only
>> indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
>> less-preferred server if that server has a better set of advertised
>> parameters, such as the available addresses advertised in IAs.").
>>=20
>> I'm definitely with Ralph here - it is much cleaner to stick to REPLY
>> only. Speaking with my chair hat off and my implementor hat on: The
>> easiest to implement is this: the option will be requested in SOLICIT
>> and REQUEST, but only the value from REPLY will actually be consumed.
>> (that how every other option is used anyway).
>>=20
>> Tomek
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>=20


From rdroms.ietf@gmail.com  Thu Jul 11 08:52:14 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 49B6421F9B38 for ; Thu, 11 Jul 2013 08:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a48R1oo7zU-p for ; Thu, 11 Jul 2013 08:52:12 -0700 (PDT)
Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id A503A21F9A3C for ; Thu, 11 Jul 2013 08:52:11 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id cz11so4454807qeb.22 for ; Thu, 11 Jul 2013 08:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=d97vpOFmeIdhXItVdC8jVZKSes5QkBnnWXH/3jOkGRc=; b=LSOudnJuXzUaMXZDSVLGu5xAh0+yiwzoUYlBb2qvdTlMeozmpv9qqTdsjNs5GpSUmD 1YY9mePObiRIE1gR1pyQNocX4r7IbYrNTWllT1nTpOd7ks0t/R9uk4e19tCAUkk40Apb 5sMYtIPkQ/FR2+BVJlideNGJ9BNGbftG5MyA7crLfzKt8fbkmAmuTDFjQL8TrnxA2V9i TtcH3pnSCQk1gUeueeygqDmzmS7qGvOxVt4oj30YWALCQQXnPxmItI+9Ir+Qw38jYvmj shSpw5IakDi8yWJO3FQE/U2riBAtvL+Fc9El35qsC4LPPXAis1eMIrQZ0tKUl2Oy5kGM V+/A==
X-Received: by 10.224.172.198 with SMTP id m6mr33485326qaz.44.1373557930285; Thu, 11 Jul 2013 08:52:10 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:58ff:687a:8198:1172? ([2001:420:2481:20:58ff:687a:8198:1172]) by mx.google.com with ESMTPSA id t18sm30315518qam.12.2013.07.11.08.52.08 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 08:52:09 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: 
Date: Thu, 11 Jul 2013 11:52:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "dhcwg@ietf.org WG" 
X-Mailer: Apple Mail (2.1508)
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 11 Jul 2013 15:52:14 -0000

BTW, rev -02 specifies that the client uses SOL_MAX_RT and INF_MAX_RT in =
any message, not just a Reply message.  My sense is that WG consensus is =
leaning toward restricting those options to Reply messages.

- Ralph

On Jul 9, 2013, at 7:34 PM 7/9/13, "Brzozowski, John" =
 wrote:

> See below.
>=20
>=20
> -----Original Message-----
> From: Tomasz Mrugalski 
> Date: Tuesday, July 9, 2013 12:56 PM
> To: Bernie Volz 
> Cc: dhc WG , Ralph Droms 
> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 =
-
> respond by July 4
>=20
>> On 09.07.2013 18:13, Bernie Volz (volz) wrote:
>>> Regarding:
>>>=20
>>>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>>>> option" should be constrained to just "receives a Reply message
>>>>> containing a SOL_MAX_RT option"?
>>>=20
>>> Don't we need clients to pick up the values in Advertises as a =
client
>>> that only receives NoAddrsAvail (which is usually not followed by
>>> Request/Reply) would never pick up the change. And if it gets to
>>> Reply stage, it likely doesn't need a new SolMax as it would likely
>>> have a lease and stop Soliciting.
>> I thought about this a bit and I actually prefer Ralph's proposal to =
use
>> only REPLY messages. Here's why:
>> - if you have legacy clients (original 3315), they won't request
>> SOLMAXRT anyway. You can't do anything about them
>> - if you have clients that implement solmaxrt, they already start =
with
>> 3600 value, so the original problem is mostly solved. They will use =
only
>> option that is delivered in the sole REPLY (as they do with every =
other
>> option).
>> - You don't have race conditions between advertises from different
>> servers sending different values in advertise.
>> - Implementation of the ADVERTISE with NoAddrsAvail would be tricky. =
The
>> text would have to say something like "client picks the value from =
that
>> ADVERTISE that it would have picked if the ADVERTISE had addresses".
> [jjmb] these are good points and I do not mean to seem like I am =
bouncing
> back and forth.  I suppose what Tomasz is suggesting would be a =
reasonable
> compromise.
>=20
>>=20
>>> Perhaps I am confused as to issue, but I think it has to do with
>>> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
>>> client only use SolMax from best (highest pref) Advertise (same as =
it
>>> would have used if it was not a NoAddrsAvail status)?
>> It's more complicated than that. Highest preference is not the only
>> indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
>> less-preferred server if that server has a better set of advertised
>> parameters, such as the available addresses advertised in IAs.").
>>=20
>> I'm definitely with Ralph here - it is much cleaner to stick to REPLY
>> only. Speaking with my chair hat off and my implementor hat on: The
>> easiest to implement is this: the option will be requested in SOLICIT
>> and REQUEST, but only the value from REPLY will actually be consumed.
>> (that how every other option is used anyway).
>>=20
>> Tomek
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>=20


From volz@cisco.com  Thu Jul 11 09:09: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 17E7321F9B89 for ; Thu, 11 Jul 2013 09:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCq5csqBnOdU for ; Thu, 11 Jul 2013 09:08:59 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A889921F9F97 for ; Thu, 11 Jul 2013 09:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14258; q=dns/txt; s=iport; t=1373558937; x=1374768537; h=from:to:cc:subject:date:message-id:mime-version; bh=HAM+a55SeeuhIIAjOocX0oG+M27DQheLd8aO4l/4jdY=; b=ioI12xjTuXNYx/kAY7xjj8ehTtfqechQ3TpCK582qzUyRtFRawpvJ4TT +uF/rpbD6advqyOW5g9v/duVzUilZl22kou1xreTe/tkTPTL6xHHCZ9EY IfgOpwjXf6OeuNluIUhU3Lzm3t/msTsgOcPw8aV18i3Q8UVsFow4vdr3B 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggGAJid3lGtJXHA/2dsb2JhbABagkVEMk2vXok4iDqBBhZ0giMBAQEELUELEgEZBAEBCx05FAkJAQQOBQiIBwy3NI8wMQaDCmwDmQOKfoUjgxGCKA
X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800";  d="scan'208,217";a="230645377"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jul 2013 16:08:08 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6BG8813014602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 16:08:08 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 11:08:08 -0500
From: "Bernie Volz (volz)" 
To: "Dhc Chairs (dhc-chairs@tools.ietf.org)" 
Thread-Topic: 2nd Request - Updated WG Milestones - Need Input from draft Authors!
Thread-Index: Ac5+UJ9gZ8PyBcDZSbaksqAvCjN6og==
Date: Thu, 11 Jul 2013 16:08:07 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185DDC1C@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.44.65.145]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185DDC1Cxmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: [dhcwg] 2nd Request - Updated WG Milestones - Need Input from draft Authors!
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, 11 Jul 2013 16:09:05 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185DDC1Cxmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please help out here! I haven't received any input!! (Please reply to chair=
s only. All will have opportunity to review the milestones a bit later once=
 we've developed a proposal.)


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B=
ernie Volz (volz)
Sent: Monday, July 01, 2013 11:48 AM
To: Dhc Chairs (dhc-chairs@tools.ietf.org)
Cc: dhcwg@ietf.org
Subject: [dhcwg] Updated WG Milestones - Need Input from Authors!

Hi:

We need to update the WG milestones as they are rather out of date (last en=
try is for Jul 2008). While Tomek and I could put milestones in which you c=
ould bash, we'd prefer to get your input into the process.

Therefore, for any WG document and explicitly mentioned items in the re-cha=
rter (see http://datatracker.ietf.org/doc/charter-ietf-dhc/), we need some =
milestones. Thus, we are asking any document authors to provide us with app=
ropriate milestones. To view what typically ends up in the milestones, plea=
se review the charters for working groups at http://datatracker.ietf.org/wg=
 (WGLC, IESG submission are typically used).

Please respond (and please only to the dhc-chairs - use REPLY, not REPLY-AL=
L) by July 12th as we'd like to distribute the draft milestones the week of=
 July 15th and discuss in Berlin (as well as on the mailing list).

Here's a start at this for some of the items Tomek and I are authors for an=
d that are key for the WG to work on:

Jul 2013  Submit SOLMAXRT to IESG
Jul 2013  Submit option guidelines to IESG
Jul 2013  Submit failover requirements to IESG
Aug 2013  WG last call on failover design
Oct 2013  Submit issues with stateful options to IESG
Oct 2013  Submit failover design to IESG
Nov 2013  Assign editor and core team for 3315-bis work
Nov 2014  WG last call on 3315-bis
Apr 2015  Submit 3315-bis to IESG

Thanks in advance and sorry for the wide distribution.


-          Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E185DDC1Cxmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Please help out here! =
I haven’t received any input!! (Please reply to chairs only. A=
ll will have opportunity to review the milestones a bit later once we’=
;ve developed a proposal.)


 


-&nb=
sp;        
Bernie


 






From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Bernie Volz (volz)

Sent: Monday, July 01, 2013 11:48 AM

To: Dhc Chairs (dhc-chairs@tools.ietf.org)

Cc: dhcwg@ietf.org

Subject: [dhcwg] Updated WG Milestones - Need Input from Authors!






 


Hi:


 


We need to update the WG milestones as they are rath=
er out of date (last entry is for Jul 2008). While Tomek and I could put mi=
lestones in which you could bash, we’d prefer to get your input into =
the process.


 


Therefore, for any WG document and explicitly mentio=
ned items in the re-charter (see
http://datatr=
acker.ietf.org/doc/charter-ietf-dhc/), we need some milestones. Thus, w=
e are asking any document authors to provide us with appropriate milestones=
. To view what typically ends up in
 the milestones, please review the charters for working groups at 
http://datatracker.ietf.org/wg (WGLC, IESG submission are typically use=
d).


 


Please respond (and please only to the dhc-chairs &#=
8211; use REPLY,
not REPLY-ALL) by July 12th as we’d like to distrib=
ute the draft milestones the week of July 15th and discuss in Be=
rlin (as well as on the mailing list).


 


Here’s a start at this for some of the items T=
omek and I are authors for and that are key for the WG to work on:


 


Jul 2013  Submit SOLMAXRT=
 to IESG


Jul 2013  Submit option g=
uidelines to IESG


Jul 2013  Submit failover=
 requirements to IESG


Aug 2013  WG last call on=
 failover design


Oct 2013  Submit issues w=
ith stateful options to IESG


Oct 2013  Submit failover=
 design to IESG


Nov 2013  Assign editor a=
nd core team for 3315-bis work


Nov 2014  WG last call on=
 3315-bis


Apr 2015  Submit 3315-bis=
 to IESG


 


Thanks in advance and sorry for the wide distributio=
n.


 


-     &=
nbsp;   
Tomek & Bernie






--_000_489D13FBFA9B3E41812EA89F188F018E185DDC1Cxmbrcdx04ciscoc_--

From rdroms.ietf@gmail.com  Thu Jul 11 09:12: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 72E5F21F992E for ; Thu, 11 Jul 2013 09:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-LYBwbugJVG for ; Thu, 11 Jul 2013 09:12:04 -0700 (PDT)
Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D7BE621F968B for ; Thu, 11 Jul 2013 09:10:55 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id ci6so7715167qab.18 for ; Thu, 11 Jul 2013 09:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=GJuXTt8v1SIdacv27F+Ngz+/IOWI4lTN881XFTby4dw=; b=jVaXXQ5u0r0HHThKq3QkyIcye+kQMLnP3L7dKWB6NOqBtDUfuGVCFqLy9rlfHxzGjM IGSC0/70G5cp9Bgiw8BL76u/A/knKEVkKE1RkWx/oDsI6Akgj/sLQvFkWeH2aX3l/wnw 07yp/0HUvnJYMgGJqmu9fSLynDKPIJLKtbxbYEX1fo11lhp/fAEruasZ9b3nOwycMOg0 iW+qqHrstHXW/TpzCCv0EyJYtzlPIk10OIW5zWxANT/yAP6ZrsrubCI3xD9F5mNh8f8m MagD4t4wnLFM5WFeRxvp3SeM/sP2d5pbWZJ1S6eFl/Wz1jh+ndL9xEEMuC3JFgdLdh2W cdrQ==
X-Received: by 10.224.103.138 with SMTP id k10mr17165440qao.42.1373559052783;  Thu, 11 Jul 2013 09:10:52 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:58ff:687a:8198:1172? ([2001:420:2481:20:58ff:687a:8198:1172]) by mx.google.com with ESMTPSA id a8sm30392788qae.11.2013.07.11.09.10.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 09:10:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: 
Date: Thu, 11 Jul 2013 12:10:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D793A14-2A33-4E18-A1FC-21DA1CD94E0F@gmail.com>
References: 
To: "dhcwg@ietf.org WG" 
X-Mailer: Apple Mail (2.1508)
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 11 Jul 2013 16:12:05 -0000

Tomek posted XML for -02 here: =
http://www.ietf.org/mail-archive/web/dhcwg/current/msg14454.html

- Ralph

On Jul 9, 2013, at 7:34 PM 7/9/13, "Brzozowski, John" =
 wrote:

> See below.
>=20
>=20
> -----Original Message-----
> From: Tomasz Mrugalski 
> Date: Tuesday, July 9, 2013 12:56 PM
> To: Bernie Volz 
> Cc: dhc WG , Ralph Droms 
> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 =
-
> respond by July 4
>=20
>> On 09.07.2013 18:13, Bernie Volz (volz) wrote:
>>> Regarding:
>>>=20
>>>>> Yeah, so perhaps "receives a message containing a SOL_MAX_RT
>>>>> option" should be constrained to just "receives a Reply message
>>>>> containing a SOL_MAX_RT option"?
>>>=20
>>> Don't we need clients to pick up the values in Advertises as a =
client
>>> that only receives NoAddrsAvail (which is usually not followed by
>>> Request/Reply) would never pick up the change. And if it gets to
>>> Reply stage, it likely doesn't need a new SolMax as it would likely
>>> have a lease and stop Soliciting.
>> I thought about this a bit and I actually prefer Ralph's proposal to =
use
>> only REPLY messages. Here's why:
>> - if you have legacy clients (original 3315), they won't request
>> SOLMAXRT anyway. You can't do anything about them
>> - if you have clients that implement solmaxrt, they already start =
with
>> 3600 value, so the original problem is mostly solved. They will use =
only
>> option that is delivered in the sole REPLY (as they do with every =
other
>> option).
>> - You don't have race conditions between advertises from different
>> servers sending different values in advertise.
>> - Implementation of the ADVERTISE with NoAddrsAvail would be tricky. =
The
>> text would have to say something like "client picks the value from =
that
>> ADVERTISE that it would have picked if the ADVERTISE had addresses".
> [jjmb] these are good points and I do not mean to seem like I am =
bouncing
> back and forth.  I suppose what Tomasz is suggesting would be a =
reasonable
> compromise.
>=20
>>=20
>>> Perhaps I am confused as to issue, but I think it has to do with
>>> which Advertise to chose when they are NoAddrsAvail cases. Shouldn't
>>> client only use SolMax from best (highest pref) Advertise (same as =
it
>>> would have used if it was not a NoAddrsAvail status)?
>> It's more complicated than that. Highest preference is not the only
>> indicator. See 17.1.3 of RFC3315 ("The client MAY choose a
>> less-preferred server if that server has a better set of advertised
>> parameters, such as the available addresses advertised in IAs.").
>>=20
>> I'm definitely with Ralph here - it is much cleaner to stick to REPLY
>> only. Speaking with my chair hat off and my implementor hat on: The
>> easiest to implement is this: the option will be requested in SOLICIT
>> and REQUEST, but only the value from REPLY will actually be consumed.
>> (that how every other option is used anyway).
>>=20
>> Tomek
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>=20


From volz@cisco.com  Thu Jul 11 09:12:35 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 44A2921F9FF5 for ; Thu, 11 Jul 2013 09:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUE8B5B5KWKY for ; Thu, 11 Jul 2013 09:12:19 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 573BB21F9A1B for ; Thu, 11 Jul 2013 09:11:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5838; q=dns/txt; s=iport; t=1373559070; x=1374768670; h=from:to:subject:date:message-id:mime-version; bh=7kQyIMVt6C493Ddc0F/IH0DdWeHsCNiO3ybia8ELCOU=; b=jiDCOAQGF0nlFkE1qDF5lQvZOx6mzaDKojJIZJaKT54IXeaLHnqt94/A 2a4DKu4zywO02mNX1AbUmm0bXelW9kBHYgm5ASPWoxKKEYSZPROr+Gi78 DFRQa6nMy5UWbp9ngrw1YM2z+CIfnj2rwxZrW6Oh3SA+bBPOWsJSbwLHx c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar8FAJid3lGtJXG+/2dsb2JhbABagkVEMk2CP78RgQYWdIIlAQQtXgEqHTkUEgEEEwiIB5cFoDuOH4ERg0FsA6kkgxGBcTc
X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800";  d="scan'208,217";a="233661011"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2013 16:10:41 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6BGAfGY014939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jul 2013 16:10:41 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 11:10:41 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: Slides for Berlin DHC WG presentations! (And last chance to request time!!)
Thread-Index: Ac5+US1wtpjb+glbSfSRNvO3R471iw==
Date: Thu, 11 Jul 2013 16:10:40 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185DDCCF@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.44.65.145]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185DDCCFxmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] Slides for Berlin DHC WG presentations! (And last chance to request time!!)
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, 11 Jul 2013 16:12:35 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185DDCCFxmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please do provide your slides if you're on the agenda (or requested time). =
Email them to the dhc-chairs@tools.ietf.org and one of us will post them.

I'll update the agenda tomorrow (assuming Tomek and I can find a time to re=
view and attempt to finalize the agenda).

If you haven't submitted a request for time, please do so ASAP. We may not =
be able to accommodate.


-          Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E185DDCCFxmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Please do provide your slides if you’re on the=
 agenda (or requested time). Email them to the
dhc-chairs@tools.ietf.org =
and one of us will post them.


 


I’ll update the agenda tomorrow (assuming Tome=
k and I can find a time to review and attempt to finalize the agenda).=



 


If you haven’t submitted a request for time, p=
lease do so ASAP. We may not be able to accommodate.


 


-     &=
nbsp;   
Tomek & Bernie






--_000_489D13FBFA9B3E41812EA89F188F018E185DDCCFxmbrcdx04ciscoc_--

From rdroms.ietf@gmail.com  Thu Jul 11 09:37: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 AB00E21F9C7D for ; Thu, 11 Jul 2013 09:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.65
X-Spam-Level: 
X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si-6dD+JSKIv for ; Thu, 11 Jul 2013 09:37:21 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2132721F9BF3 for ; Thu, 11 Jul 2013 09:37:15 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id hu16so7729747qab.8 for ; Thu, 11 Jul 2013 09:37:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer; bh=eF/41JLF4LTMUzWYiyZ6bXaZPhFz1w+2NjCJA2pG1CE=; b=09xKNeDsBXLadn3m/fKolQo3oznPqfpMYL4fENYtFxJ2pAlfmr9z3rZuK+UBLMSx4k mQhUz4lc/g1TLGBhRrkB3d6QQcw1ou8qiFDC9PfFFgofEDmC84dchTXG+JYvnpbZbjBh s0CHwQR5hk8w7NxwEW0x7yIi9kdKoYNtzw4XVn/18U0B4/9wIAUEAuTytYMlNxjh+Myc Zt9uEoPfukj0RJukqJNeL4stGKpgUf3m1Smzdk4YY1IJ6KbOxCvVuLLu6dDIVE0ZD+ib vSI6atZTZQWsEkwKSJvKht+HUWuijobkR+UKOXUOwSqyeuOfG/9Bo0ztqKNKXJPdspLg KNew==
X-Received: by 10.224.67.73 with SMTP id q9mr16025052qai.43.1373560634468; Thu, 11 Jul 2013 09:37:14 -0700 (PDT)
Received: from rtp-rdroms-8919.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id l4sm30531534qay.0.2013.07.11.09.37.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 09:37:13 -0700 (PDT)
From: Ralph Droms 
Content-Type: multipart/mixed; boundary="Apple-Mail=_92F1062A-5601-400A-A7D9-37B99C2FE50B"
Message-Id: <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Date: Thu, 11 Jul 2013 12:37:10 -0400
References: 
To: "dhcwg@ietf.org WG" 
In-Reply-To: 
X-Mailer: Apple Mail (2.1508)
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 11 Jul 2013 16:37:22 -0000

--Apple-Mail=_92F1062A-5601-400A-A7D9-37B99C2FE50B
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

.txt attached by request.

- Ralph


--Apple-Mail=_92F1062A-5601-400A-A7D9-37B99C2FE50B
Content-Disposition: attachment;
	filename=draft-ietf-dhc-dhcpv6-solmaxrt-update-02.txt
Content-Type: text/plain;
	x-unix-mode=0644;
	name="draft-ietf-dhc-dhcpv6-solmaxrt-update-02.txt"
Content-Transfer-Encoding: quoted-printable





Network Working Group                                           R. Droms
Internet-Draft                                             Cisco Systems
Updates: 3315 (if approved)                                July 11, 2013
Intended status: Standards Track
Expires: January 12, 2014


      Modification to Default Values of SOL_MAX_RT and INF_MAX_RT
                draft-ietf-dhc-dhcpv6-solmaxrt-update-02

Abstract

   This document updates RFC 3315 by redefining the default values for
   SOL_MAX_RT and INF_MAX_RT, and defining options through which a
   DHCPv6 server can override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with a new value.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Droms                   Expires January 12, 2014                [Page 1]
=0C
Internet-Draft          DHCPv6 SOL_MAX_RT Option               July 2013


1.  Introduction

   Section 5.5 of the DHCPv6 specification [RFC3315] defines the default
   values of SOL_MAX_RT and INF_MAX_RT to be 120 seconds.  In some
   circumstances, these defaults will lead to an unacceptably high
   volume of aggregated traffic at a DHCPv6 server.

   The change to SOL_MAX_RT is in response to DHCPv6 message rates
   observed at a DHCPv6 server in a deployment in which many DHCPv6
   clients are sending Solicit messages but the DHCPv6 server has been
   configured not to respond to those Solicit messages.  While no
   explicit observations of traffic due to INF_MAX_RT have been
   conducted, this document updates INF_MAX_RT for consistency with
   SOL_MAX_RT.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Updates to SOL_MAX_RT and INF_MAX_RT in RFC 3315

   This document changes section 5.5 of RFC 3315 [RFC3315] as follows:

   OLD:
      SOL_MAX_RT      120 secs  Max Solicit timeout value

   NEW:
      SOL_MAX_RT     3600 secs  Max Solicit timeout value

   OLD:
      INF_MAX_RT      120 secs  Max Information-request timeout value

   NEW:
      SOL_MAX_RT     3600 secs  Max Information-request timeout value


   With this change, a DHCPv6 client that does not receive a
   satisfactory response will send Solicit or Information-request
   messages with the same initial frequency and exponential backoff as
   specified in sections 17.1.2 and 18.1.5 of RFC 3315 [RFC3315].
   However, the long term behavior of these DHCPv6 clients will be to
   send a Solicit or Information-request message every 3600 seconds
   rather than every 120 seconds, significantly reducing the aggregated
   traffic at the DHCPv6 server.





Droms                   Expires January 12, 2014                [Page 2]
=0C
Internet-Draft          DHCPv6 SOL_MAX_RT Option               July 2013


4.  SOL_MAX_RT option

   A DHCPv6 server sends the SOL_MAX_RT option to a client to override
   the default value of SOL_MAX_RT.  The value of SOL_MAX_RT in the
   option replaces the default value defined in Section 3.  One use for
   the SOL_MAX_RT option is to set a longer value for SOL_MAX_RT, which
   reduces the Solicit traffic from a client that has not received a
   response to its Solicit messages.

   The format of the SOL_MAX_RT option is:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          option-code          |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       SOL_MAX_RT value                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         option-code          OPTION_SOL_MAX_RT (TBD).

         option-len           4.

         SOL_MAX_RT value     Overriding value for SOL_MAX_RT
                              in seconds.



                                 Figure 1

5.  INF_MAX_RT option

   A DHCPv6 server sends the INF_MAX_RT option to a client to override
   the default value of INF_MAX_RT.  The value of INF_MAX_RT in the
   option replaces the default value defined in Section 3.  One use for
   the INF_MAX_RT option is to set a longer value for INF_MAX_RT, which
   reduces the Solicit traffic from a client that has not received a
   response to its Solicit messages.

   The format of the INF_MAX_RT option is:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          option-code          |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Droms                   Expires January 12, 2014                [Page 3]
=0C
Internet-Draft          DHCPv6 SOL_MAX_RT Option               July 2013


       |                       INF_MAX_RT value                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         option-code          OPTION_INF_MAX_RT (TBD).

         option-len           4.

         INF_MAX_RT value     Overriding value for INF_MAX_RT
                              in seconds.



                    Figure 2: INF_MAX_RT option format

6.  Updates for SOL_MAX_RT and INF_MAX_RT options to RFC 3315

   Update to RFC 3315 [RFC3315], section 17.1.3:




   OLD:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

   NEW:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MUST process an included SOL_MAX_RT option and/or an
   included INF_MAX_RT option and MAY display the associated status
   message to the user.




   Update to RFC 3315 [RFC3315], section 17.2.2:



   OLD:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an
   Advertise message to the client that includes only a Status Code



Droms                   Expires January 12, 2014                [Page 4]
=0C
Internet-Draft          DHCPv6 SOL_MAX_RT Option               July 2013


   option with code NoAddrsAvail and a status message for the user, a
   Server Identifier option with the server's DUID, and a Client
   Identifier option with the client's DUID.

   NEW:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an
   Advertise message to the client that includes only a Status Code
   option with code NoAddrsAvail and a status message for the user, a
   Server Identifier option with the server's DUID, a Client
   Identifier option with the client's DUID and (optionally)
   SOL_MAX_RT and/or INF_MAX_RT options.




   Add text to the end of section 14, clarifying client behavior while
   waiting for a response from a server:



   NEW:

   A client is not expected to listen for a response during the entire
   period between transmission of Solicit or Information-Request
   messages.




7.  DHCPv6 Client Behavior

   A DHCPv6 client MUST include the SOL_MAX_RT option code in an Option
   Request option [RFC3315] in any message it sends.

   Client also MAY include option SOL_MAX_RT in its SOLICIT, REQUEST,
   RENEW, REBIND and INFORMATION-REQUEST messages as a hint for the
   server regarding preferred option values.

   If a DHCPv6 client receives a message containing a SOL_MAX_RT option,
   the client MUST set its internal SOL_MAX_RT parameter to the value
   contained in the SOL_MAX_RT option.  This value of SOL_MAX_RT is then
   used by the retransmission mechanism defined in sections 17.1.2 and
   14 of RFC 3315 [RFC3315].

   A DHCPv6 client MUST include the INF_MAX_RT option code in an Option
   Request option [RFC3315] in any message it sends.



Droms                   Expires January 12, 2014                [Page 5]
=0C
Internet-Draft          DHCPv6 SOL_MAX_RT Option               July 2013


   Client also MAY include option SOL_MAX_RT in its SOLICIT, REQUEST,
   RENEW, REBIND and INFORMATION-REQUEST messages as a hint for the
   server regarding preferred option values.

   If a DHCPv6 client receives a message containing a INF_MAX_RT option,
   the client MUST set its internal INF_MAX_RT parameter to the value
   contained in the INF_MAX_RT option.  This value of INF_MAX_RT is then
   used by the retransmission mechanism defined in sections 18.1.5 and
   14 of RFC 3315 [RFC3315].

8.  DHCPv6 Server Behavior

   Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
   regards to option assignment.  As a convenience to the reader, we
   mention here that the server will send option SOL_MAX_RT and
   INF_MAX_RT only if configured with specific values for them and the
   client requested those options using Option Request Option.

   The DHCPv6 server MAY include the SOL_MAX_RT option in any response
   it sends to a client that has included the SOL_MAX_RT option code in
   an Option Request option.  The SOL_MAX_RT option is sent in the main
   body of the message to client, not as a sub-option in, e.g., an
   IA_NA, IA_TA [RFC3315] or IA_PD [RFC3633] option.

   The DHCPv6 server MAY include the INF_MAX_RT option in any response
   it sends to a client that has included the INF_MAX_RT option code in
   an Option Request option.  The INF_MAX_RT option is sent in the main
   body of the message to client, not as a sub-option in, e.g., an
   IA_NA, IA_TA [RFC3315] or IA_PD [RFC3633] option.

9.  DHCPv6 Relay Agent Behavior Text

   There are no additional requirements for relays.

10.  Security Considerations

   This document introduces one security consideration beyond those
   described in RFC 3315 [RFC3315].  A malicious DHCPv6 server might
   cause a client to set its SOL_MAX_RT and INF_MAX_RT parameters to an
   arbitrarily high value with the SOL_MAX_RT and INF_MAX_RT options.
   Assuming the client also receives a response from a valid DHCPv6
   server, large values for SOL_MAX_RT and INF_MAX_RT will not have any
   effect.

11.  IANA Considerations

   IANA is requested to assign an option code from the "DHCP Option
   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.



Droms                   Expires January 12, 2014                [Page 6]
=0C
Internet-Draft          DHCPv6 SOL_MAX_RT Option               July 2013


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

12.2.  Informative References

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

Author's Address

   Ralph Droms
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 1674
   Email: rdroms@cisco.com
























Droms                   Expires January 12, 2014                [Page 7]

--Apple-Mail=_92F1062A-5601-400A-A7D9-37B99C2FE50B
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii




--Apple-Mail=_92F1062A-5601-400A-A7D9-37B99C2FE50B--

From volz@cisco.com  Thu Jul 11 10:59:06 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 5C3EE21FA000 for ; Thu, 11 Jul 2013 10:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA9KH5XH1tsV for ; Thu, 11 Jul 2013 10:59:01 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2A021F9C4B for ; Thu, 11 Jul 2013 10:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16295; q=dns/txt; s=iport; t=1373565541; x=1374775141; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2u3sIDfiExa057ssBc5i3uQtI9Yh5j1PuDOMuF570kI=; b=dysgxun4voEzFuJYBuswj3EM8lKkf8un7y1ZSe0C0dXgWbvjX2FYKIsa aOftkYS9kCuj3kemXJPb4BSqmR+prC+RzO7CSSMMFzwUIOBbsJnrzgrDv 8R7dsgKRuhrgDQPUdLkowG9QloeAyucFQsb411MCzu5vRaBWMEwmICCQV M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkwFAJid3lGtJV2b/2dsb2JhbABagkVEMk3BUIEGFnSCIwEBAQQBAQEqQRsCAQgOAwQBAQsdBycLFAkIAgQBEggBiAYMtzSPMA8XBwoBBoMDbAOpJIFYgTmCKA
X-IronPort-AV: E=Sophos;i="4.89,1045,1367971200";  d="scan'208,217";a="233793199"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jul 2013 17:59:00 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6BHx0kG032104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 17:59:00 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 12:59:00 -0500
From: "Bernie Volz (volz)" 
To: Ralph Droms , "dhcwg@ietf.org WG" 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOflTj1CdDi7CA1ECTcenqnRG6vplfwLew
Date: Thu, 11 Jul 2013 17:58:59 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com>
In-Reply-To: <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.44.65.145]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185DE1E8xmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -	respond by July 4
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, 11 Jul 2013 17:59:06 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185DE1E8xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

A few nits:

5.  INF_MAX_RT option

   A DHCPv6 server sends the INF_MAX_RT option to a client to override
   the default value of INF_MAX_RT.  The value of INF_MAX_RT in the
   option replaces the default value defined in Section 3.  One use for
   the INF_MAX_RT option is to set a longer value for INF_MAX_RT, which
   reduces the Solicit traffic from a client that has not received a
   response to its Solicit messages.

** This impacts Information-Request, not Solicit messages. The text needs t=
o be fixed.

8.  DHCPv6 Server Behavior
...
   body of the message to client, not as a sub-option in, e.g., an
   IA_NA, IA_TA [RFC3315] or IA_PD [RFC3633] option.

   The DHCPv6 server MAY include the INF_MAX_RT option in any response
   it sends to a client that has included the INF_MAX_RT option code in
   an Option Request option.  The INF_MAX_RT option is sent in the main
   body of the message to client, not as a sub-option in, e.g., an
   IA_NA, IA_TA [RFC3315] or IA_PD [RFC3633] option.

** Can we replace 'sub-option' with encapsulated? RFC 3315 uses 'sub-option=
' in only one place.


11.  IANA Considerations

   IANA is requested to assign an option code from the "DHCP Option
   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.

** Shouldn't this say "DHCPv6 Option Codes" registry just to be clear or "f=
rom the DHCP Option Codes table of the Dynamic Host Configuration Protocol =
for IPv6 (DHCPv6) parameters registry maintained in http://www.iana.org/ass=
ignments/dhcpv6-parameters/dhcpv6-parameters.xml"?

Otherwise, I think this draft is now hopefully ready to go to the IESG (wel=
l, the AD first).


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R=
alph Droms
Sent: Thursday, July 11, 2013 12:37 PM
To: dhcwg@ietf.org WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res=
pond by July 4

.txt attached by request.

- Ralph

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

--_000_489D13FBFA9B3E41812EA89F188F018E185DE1E8xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











A few nits:


 <=
/p>

5.  INF_MAX_RT optio=
n


 <=
/p>

   A DHCPv6 ser=
ver sends the INF_MAX_RT option to a client to override

   the default =
value of INF_MAX_RT.  The value of INF_MAX_RT in the=



   option repla=
ces the default value defined in Section 3.  One use for


   the INF_MAX_=
RT option is to set a longer value for INF_MAX_RT, which<=
/p>

   reduces the =
Solicit traffic from a client that has not received a


   response to =
its Solicit messages.


 <=
/p>

** This impacts Informati=
on-Request, not Solicit messages. The text needs to be fixed.


 <=
/p>

8.  DHCPv6 Server Be=
havior


…=



   body of the =
message to client, not as a sub-option in, e.g., an


   IA_NA, IA_TA=
 [RFC3315] or IA_PD [RFC3633] option.


 <=
/p>

   The DHCPv6 s=
erver MAY include the INF_MAX_RT option in any response

   it sends to =
a client that has included the INF_MAX_RT option code in<=
/p>

   an Option Re=
quest option.  The INF_MAX_RT option is sent in the main


   body of the =
message to client, not as a sub-option in, e.g., an


   IA_NA, IA_TA=
 [RFC3315] or IA_PD [RFC3633] option.


 <=
/p>

** Can we replace ‘=
sub-option’ with encapsulated? RFC 3315 uses ‘sub-option’=
 in only one place.


 <=
/p>

 <=
/p>

11.  IANA Considerat=
ions


 <=
/p>

   IANA is requ=
ested to assign an option code from the "DHCP Option=



   Codes" =
Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.


 <=
/p>

** Shouldn’t this s=
ay "DHCPv6 Option Codes" registry just to be clear or “from=
 the DHCP Option Codes table of the Dynamic Host Configuration Protocol for=
 IPv6
 (DHCPv6) parameters registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml=
”?


 <=
/p>

Otherwise, I think this d=
raft is now hopefully ready to go to the IESG (well, the AD first).


 <=
/p>

- =
        
Bernie=



 <=
/p>





From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Ralph Droms

Sent: Thursday, July 11, 2013 12:37 PM

To: dhcwg@ietf.org WG

Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-0=
1 - respond by July 4






 






.txt attached by request.



- Ralph










 










___________________=
____________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.ietf.or=
g/mailman/listinfo/dhcwg










--_000_489D13FBFA9B3E41812EA89F188F018E185DE1E8xmbrcdx04ciscoc_--

From sarikaya2012@gmail.com  Thu Jul 11 12:34: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 5344B21F9F3C for ; Thu, 11 Jul 2013 12:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level: 
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cONvL086Mavu for ; Thu, 11 Jul 2013 12:34:39 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 850BF21F9F37 for ; Thu, 11 Jul 2013 12:34:39 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id 10so6904325lbf.22 for ; Thu, 11 Jul 2013 12:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wbG0lAOcC+cZCIFZSS/3MH4Do7QWOgpMyYgkooyncbk=; b=BmBA0JHCsrjDQX+jbJW60GoJyLPk76EYSO6W4mQ7sJfS4Y35ZXIEsA7gk3x0Hh9yjO CbF1pmCx+JDrWslqi5sK6fsMH1OH3n+CiTZ1L3cPR+Lvw7/mqevPk+XwZkQMU4MQ2o9W Vqi5H8GTGcaxlRgI4ZZuDqjn4I+Xox1ICfJF82fLFBIq5JP5NZ5Uy2hJzo9f+tREcFvl my62ezZhqWZ/tk2W8pw5W/KyV2xoB3omc2cdEGTg9pU7BTE7yhHrDyNKmPN5wtNC6gLu r8exdYsW8knKp9/vsJKZLVKJ4iOvpuO54lqRmbpVeS2AUiDepkBDe5NAlb3nfRwF5a0L 1eyQ==
MIME-Version: 1.0
X-Received: by 10.152.6.228 with SMTP id e4mr17702223laa.61.1373571277165; Thu, 11 Jul 2013 12:34:37 -0700 (PDT)
Received: by 10.114.176.37 with HTTP; Thu, 11 Jul 2013 12:34:37 -0700 (PDT)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185DDCCF@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E185DDCCF@xmb-rcd-x04.cisco.com>
Date: Thu, 11 Jul 2013 14:34:37 -0500
Message-ID: 
From: Behcet Sarikaya 
To: "Bernie Volz (volz)" 
Content-Type: multipart/alternative; boundary=089e013d0f8a0c99bb04e1417ce4
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Slides for Berlin DHC WG presentations! (And last chance to request time!!)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jul 2013 19:34:40 -0000

--089e013d0f8a0c99bb04e1417ce4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Bernie,

A short slot for

http://tools.ietf.org/id/draft-sarikaya-dhc-vxlan-multicast-00.txt

please.

Regards,

Behcet

On Thu, Jul 11, 2013 at 11:10 AM, Bernie Volz (volz)  wrote=
:

>  Please do provide your slides if you=92re on the agenda (or requested
> time). Email them to the dhc-chairs@tools.ietf.org and one of us will
> post them.****
>
> ** **
>
> I=92ll update the agenda tomorrow (assuming Tomek and I can find a time t=
o
> review and attempt to finalize the agenda).****
>
> ** **
>
> If you haven=92t submitted a request for time, please do so ASAP. We may =
not
> be able to accommodate.****
>
> ** **
>
> **-          **Tomek & Bernie****
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

--089e013d0f8a0c99bb04e1417ce4
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Bernie,

A short slot for

http://tools.ietf.org/id/draf=
t-sarikaya-dhc-vxlan-multicast-00.txt

please.

Regards,

Behcet

On Thu, Jul 11, 2013 at 11:10 =
AM, Bernie Volz (volz) <volz@cisco.com> wrote:












Please do provide your slides if you=92re on the age=
nda (or requested time). Email them to the
dhc-chairs@t=
ools.ietf.org and one of us will post them.


=A0


I=92ll update the agenda tomorrow (assuming Tomek an=
d I can find a time to review and attempt to finalize the agenda).


=A0


If you haven=92t submitted a request for time, pleas=
e do so ASAP. We may not be able to accommodate.


=A0


-=A0=
=A0=A0=A0=A0=A0=A0=A0=A0
Tomek & Bernie







_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/dhcwg





--089e013d0f8a0c99bb04e1417ce4--

From rdroms.ietf@gmail.com  Thu Jul 11 12:56: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 EC4BE21F9E9E for ; Thu, 11 Jul 2013 12:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZD3FAckJ4Y8 for ; Thu, 11 Jul 2013 12:56:24 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3921F92BB for ; Thu, 11 Jul 2013 12:56:24 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id n1so4638221qcw.30 for ; Thu, 11 Jul 2013 12:56:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=S05K7VSCdA1PmbhdQGGZR/p+ZQC1h2RqrRu1ohw5oWg=; b=MSrQLQdGzYeM4BnM2FTp3vio9AGHwCcIgik3bMOBeaJYDb672dnE/FC4UeOMUOwZHl ENajrs/jHlLAjT79FFHo/AAgi2u9YLR3HnOcOgcQW1oZiSryQ+PfVUMTYRRoAkBd6rTj BnnYSvrpGVVF43PqFvS+35roVEBhjsbzp0ZfwGCNRSGFUAbq4dHqYkxhprkcFZXHCklS NwDLQH/j4zpV7nPUkFk0zLxxGo1RtCc+wucAmSu3Me705zpCoeiIHx+71sl5XO3BZsMr cxL3/VBpzCkeb7l0sraNWVb6gEoPnelbIhj5tGEcLLoUrbIfaJ4ubNxI5pZcx/DNRgQ0 5egw==
X-Received: by 10.49.104.35 with SMTP id gb3mr31716362qeb.77.1373572583543; Thu, 11 Jul 2013 12:56:23 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:58ff:687a:8198:1172? ([2001:420:2481:20:58ff:687a:8198:1172]) by mx.google.com with ESMTPSA id ng3sm30575578qeb.0.2013.07.11.12.56.21 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 12:56:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185CDA1C@xmb-rcd-x04.cisco.com>
Date: Thu, 11 Jul 2013 15:56:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <63C6843B-FE39-4A3D-A83B-F1EA1664DC31@gmail.com>
References: <489D13FBFA9B3E41812EA89F188F018E185CDA1C@xmb-rcd-x04.cisco.com>
To: Bernie Volz (volz) 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respond by July 15
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, 11 Jul 2013 19:56:25 -0000

Looks about ready to publish.  Some comments:

Title of section 10: "Additional States Considered Harmful"  I suggest =
s/States/State/.  At first, I thought this referred to client states as =
in DHCPv4.  The text in section 10 clearly refers to state added to the =
various kinds of state the server maintains to manage clients.

In section 13, what is a "fragment type"?  The word fragment appears =
(once) previously in section 5, but I don't have a clue what a "fragment =
type" might be.

Add citations to RFC 2131 and RFC 2132 for the references to DHCPv4?

- Ralph

On Jul 1, 2013, at 5:44 PM 7/1/13, Bernie Volz (volz)  =
wrote:

> The draft-ietf-dhc-option-guidelines-12, =
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12, =
addresses the comments from the previous (-11) last call. While =
originally I expected to have a short (1 week) last call for the updated =
document, I think it best to have the standard 2 weeks given the time of =
year (and the Independence Day holiday in the US).
> =20
> Please review the draft and indicate whether or not you feel this =
version is ready to be published. Your response matters to the process, =
so please do respond.
> =20
> Do note: While I encourage full reviews, the main focus is to assure =
we have consensus on the recent changes from the -11. The -11 WGLC =
support will be taken into consideration.
> =20
> As Tomek is an author, I will evaluate consensus after July 15, 2013.
> =20
> -          Bernie
> =20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


From kkinnear@cisco.com  Thu Jul 11 13:21:00 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 4997721F99A9 for ; Thu, 11 Jul 2013 13:21:00 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTncv+ZsEWef for ; Thu, 11 Jul 2013 13:20:54 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3545C21F994C for ; Thu, 11 Jul 2013 13:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16715; q=dns/txt; s=iport; t=1373574053; x=1374783653; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KUxtpIAR3aHHMJ1xgccGDprkUdyfGEnsssyMhusgjJU=; b=GZ1eOaOETRuk9FXAlhRjG6wLBJh4X+qIUL31f1DJycYBvCZe699/CJer 3BeFrBTzEhOX111qEERHDO/6YjWpScLieodJSOnTtlHQXIrlI7lxMpg8B me9fWZBzDUDZ3fDSTcvoUpw4Xxawfw1ztJLn7Jw+5U7chumUl0yGbYwHb U=;
X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="233772347"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 11 Jul 2013 20:20:53 +0000
Received: from printer-xerox-test-5735.cisco.com (printer-xerox-test-5735.cisco.com [161.44.65.115]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6BKKpIt029555;  Thu, 11 Jul 2013 20:20:52 GMT
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Kim Kinnear 
In-Reply-To: <1363117384.2123.64.camel@marcin-lenovo>
Date: Thu, 11 Jul 2013 16:20:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <56D269DB-423A-49C3-83E2-C58FE5FB8DA1@cisco.com>
References: <1363117384.2123.64.camel@marcin-lenovo>
To: Marcin Siodelski 
X-Mailer: Apple Mail (2.1278)
Cc: "dhcwg@ietf.org" , Kim Kinnear 
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-design-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: Thu, 11 Jul 2013 20:21:00 -0000

Marcin,

Thanks very much for your comments.  I apologize that it has taken
us so long to get back to you regarding them.

My responses to your comments are indented, inline, below.

On Mar 12, 2013, at 3:43 PM, Marcin Siodelski wrote:

> Hi,=20
>=20
> I have read the version -02 of the draft. This is a useful work and I
> support it move forward.
>=20
> Some first round of comments...
>=20
> 2. Glossary:
> - The "Failover transmission" is defined in the glossary but it is =
used
> nowhere in the draft. Perhaps you meant "Failover communication" which =
is
> common in the text.

	Sure, good idea.
>=20
> 3. Introduction
> - The document says that the failover protocol is not suitable for =
lease
> times shorter than 30sec. Then, is it suitable for lease times of 31s?
> Why is that arbitrary number selected? I believe that the document
> should simply mention that there is an additional overhead on the =
server=20
> related to failover transmission (that would justify use of this term =
in=20
> the glossary) and thus it is not efficient for short lease times.

	While the actual time selected is arbitrary, the need for a
	a minimum time is not based so much on efficiency as it is
	on the need to handle time skew (Section 8.1) effectively.
	We chose 30 seconds as a value which was long enough to=20
	allow a reasonable implementation to handle time skew, but
	not so long that anyone would really care about using
	leases that short.
>=20
> 3.1. Perhaps, it is worth to replace the title from "Additional
> Requirements" with "Design Requirements" to indicate that it is not
> extending the protocol requirements described elsewhere.

	Sure.
>=20
> 4. Protocol Overview
> - The hyperlink to "Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460]" =
is
> broken because clicking on "Section 5.1" takes you to the section 5.1 =
in
> the local document.

	Thanks, we'll see what we can do about this.
>=20
> - Is it worth to mention that if the primary server can't establish
> communication with the secondary server (because secondary is down) it
> will attempt to connect with the implementation dependent interval?

	Sure.  Will reference Section 5.1 where this is described.
>=20
> 4.1. Failover State Machine Overview
> - It is not clear what the state the partner goes to, when the
> DISCONNECT occurs. I presume it is PARTNER-DOWN state but the document
> should clarify it.

	For sure, since it is not PARTNER-DOWN, but rather=20
	COMMUNICATIONS-INTERRUPTED.  This is because the re-integration
	from COMMUNICATIONS-INTERRUPTED is much easier (more efficient,
	quicker) than that from PARTNER-DOWN.
>=20
> - Here is a sentence: "In case of a disagreement between the =
simplified
> and complete description, please follow Section 9". I think that there
> must be no "disagreement" between those two sections. The one provides =
a
> supplementary information for the other but they should remain
> consistent in the common part.
=09
	I agree that there must not be a disagreement, and we will =
ensure
	that we don't see any.  However, since information is left out
	of the overview, we have to have a statement like this in
	the document (or take out the overview).  Describing the same
	thing in two different places without some way to resolve
	(apparent) differences is a bad idea.  I am sure that some
	readers will perceive a disagreement, even though I will
	not.
>=20
> - I don't understand the purpose of: "It frequently returns back to =
the
> state it was in before shutdown". Perhaps, some context needs to be
> provided for it?

	Will do.  I think this pretty much says that you need to=20
	remember the state you were in before you shut down.
>=20
> - In the 4th paragraph "in unresponsive" should be replaced with "is
> unresponsive".

	Yes.

> However, I am wondering if it is correct given that
> extensions may introduce "active-active" mode in which this is not =
true
> anymore. Perhaps, it could be mentioned that "assuming that failover
> pair is in the active-passive mode, the secondary server is =
unresponsive
> when in NORMAL state".=20

	We can't write this draft and take in account all of the
	extensions that will come (though that will certainly
	be one of them).  The extensions will specify the necessary
	changes.
>=20
> - A bit of clarification would be needed on what the =
"auto-partner-down"
> is - glossary? Is this that the server bypasses the
> COMMUNICATION-INTERRUPTED state and goes straight to PARTNER-DOWN or =
it
> goes to COMMUNICATION-INTERRUPTED state then to PARTNER-DOWN? If the
> latter is the case, then would it state in the =
COMMUNICATION-INTERRUPTED
> state for a while, trying to reconnect?

	Good point.  We'll put that in the glossary.  The =
auto-partner-down
	capability is where the server goes into =
COMMUNICATIONS-INTERRUPTED
	state and, after waiting a while, automatically goes into
	PARTNER-DOWN state.  It *always* is trying to reconnect, =
regardless
	of the state it is in.=20
>=20
> - I don't understand what is meant by "When a server does not have an
> intact lease state database (e.g. due to first time run or =
catastrophic
> failure) ..."? First of all, is the lease state data base the database
> which holds leases or it holds some additional information about the
> server state prior to the failure, which can be used to determine that
> the catastrophic failure occured? Also, the "doesn't have an intact
> lease state database" formulation is misleading because I think that =
the
> server on its first time DOES have the intact database.

	The presumption is that the information about whether you
	have talked to the partner in the past or not is held in
	the same database as the lease information.  So that if you
	lose one of these, you will lose them both.

	Yes, the database is intact, but it is empty.  This is where=09
	the simplified description here is ... simplified.  There are
	two different scenarios:

	a) The other server says "I've talked to you before at time x"
	and the receiving server has no record of having talked to
	the other server.  That is not an "intact" lease-state-database.

	b) The other server says "I've never talked to you before", and
	you agree, but you are a backup, so you go into RECOVER state.

	We will clarify this.
>=20
> - The RECOVER-WAIT to RECOVER-DONE transition could be better =
described.
> Specifically, what condition it is triggered by?
=09
	For sure.  See Section 9.6.2.  We felt that moving that
	information into this section (or even a stripped down
	version), would overwhelm this overview.
>=20
> - Is there any way out from the RESOLUTION-INTERRUPTED? If the
> communication is reestablished I presume that both servers continue
> resolving conflicts?

	See Section 9.11.2.  Again, this is an overview.
>=20
> 4.2. Messages
> - I suggest that the following description of the CONNECT message:
> "The partner is expected to confirm by responding with CONNECTACK" is
> reworded to "The partner MUST confirm by responding with CONNECT ACK".

	I was going to say sure, but then I remembered why we didn't
	make this a MUST originally.  See the comment below on 5.1,
	Creating Connections.
>=20
> - Perhaps, the same applies to some other types of messages but I did =
not
> check that thoroughly enough to put this into this review.
>=20
> - Minor: it would be easier to search for the specific message
> description if the messages were ordered alphabetically.=20

	True.  Always an issue.  Alpha or by importance, or functional
	grouping, or what.  We chose some variant of importance.
>=20
> - The POOLRESP is used everywhere throughout the document, while it is
> called "POOLRSP" in the list of messages.

	Thanks, we'll fix that.
>=20
>=20
> 5.1. Creating Connections
> - "If it has no secondary relationships with the connecting server, it
> SHOULD drop the connection". This sentence suggests that the secondary
> server will not respond to the initiating server if it has no
> relationship with it. A couple of paragraphs earlier, it was said the
> server "is expected" or MUST respond with CONNECTACK. I suggest that =
it
> is reworded to explain that the server MUST reject the connection by
> sending the CONNECTACK with the reason for rejection instead of
> "dropping".

	Geez.  Get me to make it a MUST, and then complain that=20
	the document doesn't follow the MUST?  Nice try :-)

	Seriously, we don't want to require that a connection from
	another (rogue?) server require any more processing than
	just to drop the connection. =20
>=20
> 6.1. Proportional Allocation
> - The paragraph which starts with "The initial allocation when..." is
> confusing.

> If I understand correctly, the POOLRESP is devoted to deliver
> the actual resources to the secondary server. The document says that =
it
> is to inform a secondary server "how many resources it allocated". =
This
> doesn't sound to be the same.

	It isn't the same.  The POOLREQ is supposed to cause the
	primary server to examine the various prefixes and ensure that
	the secondary has what it is supposed to have.  The POOLRESP
	is the message that says to the secondary that the primary has
	done the examination.  The POOLRESP doesn't return anything
	other than the information that the scan has completed
	and how many leases/prefixes that will be forthcoming.
>=20
> - I am wondering why at all, the POOLREQ/POOLRESP exchange has to be
> initiated by the secondary server. In the scenario where the failover
> configuration is handled through the primary server it is primary =
server
> who should notify the secondary that the (for example) pool balance =
has
> been changed.

	The primary doesn't have to tell the secondary that the balance
	has been changed.  It just sends the changes in BNDUPD packets.

> This implies the primary could initiate the exchange by
> notifying the secondary server that the rebalancing will start now.

	The primary doesn't have to notify that secondary that
	the rebalancing will (or has) started.

> On the other hand in the "Proportional Allocation" scenario the =
rebalancing
> may be started when the secondary has returned addresses to the =
primary
> which had been released by the client. However, in such case the =
primary
> should also be aware of the need to rebalance and could also start the
> rebalancing procedure. So again, I don't understand why the secondary =
is
> starting the rebalancing procedure here?

	Typically, the primary will do rebalancing on its own
	only for portions of the address space.  The POOLREQ
	allows the secondary to request a scan of the entire address
	space.=20
>=20
> - Another related question: is this really required to do an extra
> POOLREQ/POOLRESP exchange while the actual transfer of addresses is
> later done via BNDUPD/BNDACK? What extra information will
> be carried in the POOLREQ/POOLRESP messages that needs to be delivered
> prior to sending BNDUPD/BNDACK which actually delegate resources by
> modifying state FREE to FREE_BACKUP or the other way around?

	The information that the scan has completed is the real
	information that is transmitted by the POOLRESP.  The=20
	POOLREQ transmits the desire for a full scan of the=20
	address space.

	In many cases (hopefully in most), the primary will keep
	things balanced.  It will do this balancing in an implementation
	specific manner, and with an implementation specific frequency.

	However, the POOLREQ/POOLRESP messages are a way for the
	secondary to ensure that a full scan has been performed
	by the primary.
>=20
> - "...and the secondary server is responsible for being configured in
> such a way". Well, the server is not responsible for anything.
> Administrator might be responsible to configure the server, the
> developer is responsible to ensure the proper implementation, but the
> server is not responsible...

	Good point.  We'll fix this.
>=20
> 6.2. Independent Allocation
> - It is mentioned that the resources are allocated/split as a part of
> initial connection establishment. How? Specifically, are resources
> delegated to the secondary server using the same messages as used for
> "Proportional Allocation"?

	No, we need to clarify this.  Independent allocation is
	essentially algorithmic -- each server is configured in such
	a way that it *knows* which IP addresses it has available
	for allocation.  The actual IP address are available for
	allocation are *not* transmitted over the wire as they
	are for proportional allocation.

>  If so, what happens if the primary server
> requests reallocation of resources later on? Is this rejected by the
> primary server? Is this request dropped?

	I think you meant "... what happens if the secondary server =
requests ..."
	Good question.  The primary server scans the address space
	that is currently using proportional allocation, and ignores
	the address space using independent allocation.
>=20
> 6.3. Choosing Allocation Algorithm
> - Typo in "indepentent".

	Thanks.
>=20
> 7. Information Model
> - Instead of referring to "DHCP RFC" the link to the actual RFC along
> with its number should be provided.

	Sure.
>=20
> - Typo in "untile"

	Yes.
>=20
> 8. Failover Mechanisms
> - The last sentence is redundant as the previous one says pretty much
> the same.

	Sure.
>=20
> 8.4. MCLT Concept
> - The paragraph which starts with "The fundamental relationship
> which..." is a little bit obscure. I suggest that it is reworded to
> something like: "The fundamental relationship on which much of the
> correctness of this protocol depends is that the lease expiration time
> known to DHCPv6 client MUST NOT be greater by more than MCLT, than the
> potential expiration time known to a server's partner.=20

	Sure, thanks.
>=20
>=20
> 8.10. Acknowledging Reception
> - This section is empty. At least TBD would be useful. Otherwise it =
suggests
> that this part has been accidentally omitted.=20

	Yes, it was accidentally omitted.  There is text there
	in the .xml file.  Have to figure out why it isn't
	coming out...
>=20
> 9.1. State Machine Operation
> -  One additional event that may cause transition from one state to
> another is probably administrator's intervention?

	In some implementations, sure.  Not required
	by the design, though.
>=20
> 9.3.2. Transition Out of Startup State
> - The part that describes Step 2 is intricate. I read it a couple of
> times and I still don't feel I understand it. Perhaps, it could be =
split
> into a couple of simpler sentences.

	I'll try...
>=20
> 9.4. PARTNER-DOWN State
> - It may be worth to give a hint how the server may end-up being in =
this
> state. Most likely it is because his partner had stopped responding.
> However, in this case they are in the COMMUNICATION-INTERRUPTED state
> and there is some other event (what?) that needs to occur to =
transition
> to the PARTNER-DOWN state.

	Good point.  Great point.  I'll fix this up.

	The event is typically operation intervention, though
	it could be the auto-partner-down thing we discussed=20
	earlier.
>=20
> 9.11. RESOLUTION-INTERRUPTED
> - In the introduction to this chapter it is pointed out that if the
> server's remained in the POTENTIAL-CONFLICT state and the resolution =
of
> the conflict was interrupted, they transition to =
RESOLUTION-INTERRUPTED
> and they are unresponsive to clients

	I don't see the statement about being unresponsive to clients.
	Could you point me at it more specifically?

> (I presume this is because they
> were unresponsive when being in POTENTIAL-CONFLICT state and the
> conflict is still assumed to be present).

	No, not really.  That is the point of RESOLUTION-INTERRUPTED
	state -- they can attempt to do *something*, and not just
	sit there waiting for the partner.

> If you take a look at the
> 9.11.1. it is said that the server MUST respond to all DHCP client
> requests. That looks contrary to the previous statement.

	Indeed, but I can't find the previous statement...
> My
> understanding is that the server can't respond in the
> RESOLUTION-INTERRUPTED state thus it requires administrative
> intervention.

	I don't know where in the document you got that idea
	from, but I'd like to fix it.

	-----------------------------------

	Thanks for the great review!

	Regards -- Kim

>=20
> Cheers,
> Marcin
>=20
>=20
>=20


From tomasz.mrugalski@gmail.com  Fri Jul 12 04:02: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 11B5221F9DB8 for ; Fri, 12 Jul 2013 04:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level: 
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcFqVLSgpuLS for ; Fri, 12 Jul 2013 04:02:39 -0700 (PDT)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2895221F9D42 for ; Fri, 12 Jul 2013 04:02:38 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id jm2so3736967bkc.30 for ; Fri, 12 Jul 2013 04:02:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=hjZmuGumaUi3Jxzyuj5C97mbCtgYQet5Ok6HWJjlS9A=; b=DM7fYVhEXHc0JsCoQNipoJbsiYHJ2F5dkqJ9xCPsQbY4T80085s5MEw7Tnvd2yUF7H hpfgZWNQ6f/haSzdnNhvplCzmWEPbgWHhIIANBnveiedpAPIQ7I0EiVAA1HLM2LNT0Xf 173SCJXycGWxmQ6J6/GuqzvOraq8LVnCJ76D2+i5696zl9zoeIiHSeDdunWldxCuEE4H KhuTfNFicZ3XteC9M3payhre3pq/bLdkVKkzbNdt6Dk1OAITW9ywre9GRfEjaJ9SNt1x 3ibZdQs0NZf5RwDynn4TTGISFuTYsArqD7FKoK4Ejdj6ATNJz0G+R5+0Ob6vkAwjrrqZ tjcg==
X-Received: by 10.205.12.67 with SMTP id ph3mr6155105bkb.87.1373626956953; Fri, 12 Jul 2013 04:02:36 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id px7sm9087330bkb.9.2013.07.12.04.02.34 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 04:02:35 -0700 (PDT)
Message-ID: <51DFE245.6080909@gmail.com>
Date: Fri, 12 Jul 2013 13:02:29 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Bernie Volz (volz)" 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130712130229004
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 11:02:40 -0000

On 11.07.2013 19:58, Bernie Volz (volz) wrote:
> 11.  IANA Considerations
>    IANA is requested to assign an option code from the "DHCP Option
>    Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
> ** Shouldn’t this say "DHCPv6 Option Codes" registry just to be clear or
> “from the DHCP Option Codes table of the Dynamic Host Configuration
> Protocol for IPv6 (DHCPv6) parameters registry maintained in
> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml”?
I was surprised with this one, but "DHCP Option Code" is the correct
name for DHCPv6 options registry. DHCPv4 options are listed in "BOOTP
Vendor Extensions and DHCP Options" registry. I would have named those
registries differently, but I suppose there's no procedure (or a real
need) to rename them. I think the text in IANA considerations is a bit
minimalistic, but correct.

Or perhaps not. One minor correction: "an option code" => "option codes".

> Otherwise, I think this draft is now hopefully ready to go to the IESG
> (well, the AD first).
Bernie, what's your opinion: should those options be consumed by client
from Advertise and Reply messages or from Reply only?

Tomek

From volz@cisco.com  Fri Jul 12 05:15:00 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 A9E8811E80E1 for ; Fri, 12 Jul 2013 05:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.566
X-Spam-Level: 
X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIo62Sn300iG for ; Fri, 12 Jul 2013 05:14:56 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1E79821E804D for ; Fri, 12 Jul 2013 05:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1964; q=dns/txt; s=iport; t=1373631296; x=1374840896; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=srDFibjUtT3KySkcLsI4idClHSLwPMuIHogll2h48bE=; b=GQftZ1WQf0hxUlH37RaznQ33AIpmMjmR2oH1V2hG1Z7EqdUDtwHcrM9N m/38jIHdxTu059IzK/7eKEhcHHhsM+hXKu7ly7pC9e3m38ogmfR4eFcuQ 5G4XVGrmPMyk2uio9d/DlTQIWbe9oJ1mndQEswsKxIAhtg7TQvHlmCLag E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAOzx31GtJXG8/2dsb2JhbABagwY0wiCBCRZ0giMBAQEDAQEBASRHCwULAgEIDgouIQYLJQIEDgUJh3QDCQYMriMNiF6MeII2MweDC2wDlXOBaYwnhSaBWYE5
X-IronPort-AV: E=Sophos;i="4.89,652,1367971200"; d="scan'208";a="233987867"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 12 Jul 2013 12:14:55 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6CCEtPG018685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 12:14:55 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 07:14:55 -0500
From: "Bernie Volz (volz)" 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfu9WNsz9QllL4k6dStCNj7Oo55lg9Pda
Date: Fri, 12 Jul 2013 12:14:54 +0000
Message-ID: 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>
In-Reply-To: <51DFE245.6080909@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 12:15:00 -0000

The main reason for this was to handle situation where server didn't give a=
ddresses to client - thus just a Solicit/Advertise cycle (client has nothin=
g to Request, so no Reply).

But because default has changed (120 -> 3600), it will reduce rate of Solic=
its. Might have been nice if server (via Advertise) could increase value fu=
rther (1 day...).

If you thus just do this on the Reply, the utility of SOLMAX option is real=
ly lost.

- Bernie (from iPad)

On Jul 12, 2013, at 7:02 AM, "Tomek Mrugalski" =
 wrote:

> On 11.07.2013 19:58, Bernie Volz (volz) wrote:
>> 11.  IANA Considerations
>>   IANA is requested to assign an option code from the "DHCP Option
>>   Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
>> ** Shouldn=92t this say "DHCPv6 Option Codes" registry just to be clear =
or
>> =93from the DHCP Option Codes table of the Dynamic Host Configuration
>> Protocol for IPv6 (DHCPv6) parameters registry maintained in
>> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml=
=94?
> I was surprised with this one, but "DHCP Option Code" is the correct
> name for DHCPv6 options registry. DHCPv4 options are listed in "BOOTP
> Vendor Extensions and DHCP Options" registry. I would have named those
> registries differently, but I suppose there's no procedure (or a real
> need) to rename them. I think the text in IANA considerations is a bit
> minimalistic, but correct.
>=20
> Or perhaps not. One minor correction: "an option code" =3D> "option codes=
".
>=20
>> Otherwise, I think this draft is now hopefully ready to go to the IESG
>> (well, the AD first).
> Bernie, what's your opinion: should those options be consumed by client
> from Advertise and Reply messages or from Reply only?
>=20
> Tomek
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

From rdroms.ietf@gmail.com  Fri Jul 12 05:54:34 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 7E98E21F9B03 for ; Fri, 12 Jul 2013 05:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx3v9HhcliJj for ; Fri, 12 Jul 2013 05:54:33 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 850E521F9A4B for ; Fri, 12 Jul 2013 05:54:33 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id n1so4912239qcw.16 for ; Fri, 12 Jul 2013 05:54:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WaN2jF2dr6mSyFKgA0JBil/+gYhKzJ8GuW2fC5ygFi8=; b=Hrj8vq5+/AY2fsXLB+SG2o8KXn4agxSVRgwIOMrN0rPoEiKJAQWmswynfU5zsk2GY+ E16bGGPWvqc8Kmqh+kv/ewCUefbltU6lHyT+n5uNoMD4qS1XjLo0otEzka6uC6BWPfT+ M3+2wTOglqZyL5g7l2pjK8T0kFcftqdd9zxvgIu2CxtbSdJrbC64Xuf5XOmBEpLKF8XU n/BEb6TCeDqUg2f1eRAnJt38mnlSsxt8IgLS0xpvzHf2o8LnSatEGUHtnlHTS+5mYycs 6F8kKcPio90lDAQ2Vm09DUtSquhDK5XMJuRqplF3qW7pthvF/+uvYIh6oMIpdC7OLSqM jG7A==
X-Received: by 10.224.173.2 with SMTP id n2mr36626857qaz.75.1373633672909; Fri, 12 Jul 2013 05:54:32 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:4d2:4fa1:1c00:b229? ([2001:420:2481:20:4d2:4fa1:1c00:b229]) by mx.google.com with ESMTPSA id i1sm34622768qas.10.2013.07.12.05.54.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 05:54:32 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: 
Date: Fri, 12 Jul 2013 08:54:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com> 
To: "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 12:54:34 -0000

On Jul 12, 2013, at 8:14 AM 7/12/13, "Bernie Volz (volz)" =
 wrote:

> The main reason for this was to handle situation where server didn't =
give addresses to client - thus just a Solicit/Advertise cycle (client =
has nothing to Request, so no Reply).

Ah, right, of course.

>=20
> But because default has changed (120 -> 3600), it will reduce rate of =
Solicits. Might have been nice if server (via Advertise) could increase =
value further (1 day...).
>=20
> If you thus just do this on the Reply, the utility of SOLMAX option is =
really lost.

Agreed.

But I'm concerned that we're letting the perfect be the enemy of the =
good in what should be a really simple use case.

Perhaps we can just drop the idea of the options altogether.  They will =
only be of value in devices that also use default SOLMAXRT =3D=3D 3600.  =
Is changing the default enough to skate us past this transition case?

If so, I apologize for introducing the extra complexity w/o considering =
the consequences.  Lesson learned...

- Ralph

>=20
> - Bernie (from iPad)
>=20
> On Jul 12, 2013, at 7:02 AM, "Tomek Mrugalski" =
 wrote:
>=20
>> On 11.07.2013 19:58, Bernie Volz (volz) wrote:
>>> 11.  IANA Considerations
>>>  IANA is requested to assign an option code from the "DHCP Option
>>>  Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
>>> ** Shouldn=92t this say "DHCPv6 Option Codes" registry just to be =
clear or
>>> =93from the DHCP Option Codes table of the Dynamic Host =
Configuration
>>> Protocol for IPv6 (DHCPv6) parameters registry maintained in
>>> =
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml=94=
?
>> I was surprised with this one, but "DHCP Option Code" is the correct
>> name for DHCPv6 options registry. DHCPv4 options are listed in "BOOTP
>> Vendor Extensions and DHCP Options" registry. I would have named =
those
>> registries differently, but I suppose there's no procedure (or a real
>> need) to rename them. I think the text in IANA considerations is a =
bit
>> minimalistic, but correct.
>>=20
>> Or perhaps not. One minor correction: "an option code" =3D> "option =
codes".
>>=20
>>> Otherwise, I think this draft is now hopefully ready to go to the =
IESG
>>> (well, the AD first).
>> Bernie, what's your opinion: should those options be consumed by =
client
>> from Advertise and Reply messages or from Reply only?
>>=20
>> Tomek
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg


From volz@cisco.com  Fri Jul 12 06:23: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 172A821E8096 for ; Fri, 12 Jul 2013 06:23:25 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIKldBmpcE5C for ; Fri, 12 Jul 2013 06:23:20 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4415921E804D for ; Fri, 12 Jul 2013 06:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3865; q=dns/txt; s=iport; t=1373635400; x=1374845000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DhnojFaWCseqLvre75vKZkSEpS2r5zhZHbHFN5X0WX8=; b=eWWErdeuqTkGF4EWt8LKdqDIyyF4g4ap7B8GtQkhykZGnBMXFBX1Xx7b yNGCvZBEQbtbGP885XffUADdxYlijg6LTaBV8pknq57FFcoksi99gwNx8 vlLCG2U0oN2DfLiFlhmcnn4B466vnJilLYP16WAz1JIq45CdjoPnLLPZx E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAMgC4FGtJV2Y/2dsb2JhbABagwY0wiCBCRZ0giMBAQEDAQEBASRHCxACAQgOCi4hBgslAgQOBQmHdAMJBgyuNQ2IXox4gjYzB4MLbAOVc4FpjCeFJoFZgTmBaAY
X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234039381"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jul 2013 13:23:19 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6CDNJNo028489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 13:23:19 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 08:23:19 -0500
From: "Bernie Volz (volz)" 
To: Ralph Droms 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfv74C2mZ4sLtA0SzmbFVE+f0XZlhB/Na
Date: Fri, 12 Jul 2013 13:23:18 +0000
Message-ID: 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com> , <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
In-Reply-To: <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -	respond by July 4
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, 12 Jul 2013 13:23:25 -0000

While the text around which advertise's SOLMAX to take isn't very clear, it=
 was I believe Tomek that had the main concerns. In thinking this through, =
in practice I don't see that this makes that much difference as "good" serv=
ers should all have the same values. And "bad" servers are hard to weed out=
 anyway and can always craft packets that would be "preferred" over others =
- and I would think they'd prefer to give the client "their" service rather=
 than telling the client to try less often - with the retransmission algori=
thm it still gives the real server plenty of opportunity to get a packet to=
 the client (it isn't as if receiving SOLMAX means to set the next retransm=
ission interval to that value and real offers of service will still be acce=
pted). So a DoS attack using this isn't likely to be that effective unless =
the real servers' traffic can also be blocked.

- Bernie (from iPad)

On Jul 12, 2013, at 8:54 AM, "Ralph Droms"  wrote:

>=20
> On Jul 12, 2013, at 8:14 AM 7/12/13, "Bernie Volz (volz)"  wrote:
>=20
>> The main reason for this was to handle situation where server didn't giv=
e addresses to client - thus just a Solicit/Advertise cycle (client has not=
hing to Request, so no Reply).
>=20
> Ah, right, of course.
>=20
>>=20
>> But because default has changed (120 -> 3600), it will reduce rate of So=
licits. Might have been nice if server (via Advertise) could increase value=
 further (1 day...).
>>=20
>> If you thus just do this on the Reply, the utility of SOLMAX option is r=
eally lost.
>=20
> Agreed.
>=20
> But I'm concerned that we're letting the perfect be the enemy of the good=
 in what should be a really simple use case.
>=20
> Perhaps we can just drop the idea of the options altogether.  They will o=
nly be of value in devices that also use default SOLMAXRT =3D=3D 3600.  Is =
changing the default enough to skate us past this transition case?
>=20
> If so, I apologize for introducing the extra complexity w/o considering t=
he consequences.  Lesson learned...
>=20
> - Ralph
>=20
>>=20
>> - Bernie (from iPad)
>>=20
>> On Jul 12, 2013, at 7:02 AM, "Tomek Mrugalski"  wrote:
>>=20
>>> On 11.07.2013 19:58, Bernie Volz (volz) wrote:
>>>> 11.  IANA Considerations
>>>> IANA is requested to assign an option code from the "DHCP Option
>>>> Codes" Registry for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT.
>>>> ** Shouldn=92t this say "DHCPv6 Option Codes" registry just to be clea=
r or
>>>> =93from the DHCP Option Codes table of the Dynamic Host Configuration
>>>> Protocol for IPv6 (DHCPv6) parameters registry maintained in
>>>> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xm=
l=94?
>>> I was surprised with this one, but "DHCP Option Code" is the correct
>>> name for DHCPv6 options registry. DHCPv4 options are listed in "BOOTP
>>> Vendor Extensions and DHCP Options" registry. I would have named those
>>> registries differently, but I suppose there's no procedure (or a real
>>> need) to rename them. I think the text in IANA considerations is a bit
>>> minimalistic, but correct.
>>>=20
>>> Or perhaps not. One minor correction: "an option code" =3D> "option cod=
es".
>>>=20
>>>> Otherwise, I think this draft is now hopefully ready to go to the IESG
>>>> (well, the AD first).
>>> Bernie, what's your opinion: should those options be consumed by client
>>> from Advertise and Reply messages or from Reply only?
>>>=20
>>> Tomek
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

From bs7652@att.com  Fri Jul 12 06:24: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 E25AD11E8100 for ; Fri, 12 Jul 2013 06:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxd5FFHsWAFd for ; Fri, 12 Jul 2013 06:24:09 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0430011E80F3 for ; Fri, 12 Jul 2013 06:24:08 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 97300e15.2aaae4c2d940.3203752.00-553.8916694.nbfkord-smmo06.seg.att.com (envelope-from );  Fri, 12 Jul 2013 13:24:09 +0000 (UTC)
X-MXL-Hash: 51e00379583ce922-76c30c7cd12d5718ef79e142dc808cee1a103766
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 77300e15.0.3203744.00-266.8916645.nbfkord-smmo06.seg.att.com (envelope-from );  Fri, 12 Jul 2013 13:24:08 +0000 (UTC)
X-MXL-Hash: 51e0037849ec0b83-9333f26e974afda54248927679c774dfabf1c0b2
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6CDO7ao017636; Fri, 12 Jul 2013 09:24:07 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6CDNq8c017507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 09:24:00 -0400
Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 12 Jul 2013 13:23:46 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Fri, 12 Jul 2013 09:24:11 -0400
From: "STARK, BARBARA H" 
To: Ralph Droms , "Bernie Volz (volz)" 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfv8Kb0H+k/eG6U+4hzQZ9PDEmJlhBsHg
Date: Fri, 12 Jul 2013 13:24:10 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6113030D0BE@GAALPA1MSGUSR9L.ITServices.sbc.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
In-Reply-To: <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.142.102]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a]
X-AnalysisOut: [=LYGM54nb_94A:10 a=8D1Zlw_bSjwA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Q47MkUNJBF8A:10 a=x-uDxcd_pAPZe6k73nIA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10 a=k21SiULxh88A:10 a=2ZjEwTRH0_sA:10]
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -	respond by July 4
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, 12 Jul 2013 13:24:16 -0000

> Perhaps we can just drop the idea of the options altogether.  They will o=
nly
> be of value in devices that also use default SOLMAXRT =3D=3D 3600.  Is ch=
anging
> the default enough to skate us past this transition case?

I don't see the options as necessary to the problem we're trying to solve a=
nd would not object to dropping them.
Barbara

From rdroms.ietf@gmail.com  Fri Jul 12 06:27: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 8306B21F9967 for ; Fri, 12 Jul 2013 06:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar3Ry6KCdnWg for ; Fri, 12 Jul 2013 06:27:20 -0700 (PDT)
Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFFB21F9E0B for ; Fri, 12 Jul 2013 06:27:17 -0700 (PDT)
Received: by mail-qe0-f42.google.com with SMTP id s14so5129956qeb.15 for ; Fri, 12 Jul 2013 06:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=oo/vvw+G2cEy+sh114BC022lp4Goe477k0XYDTDl2so=; b=Pyd+RzFk18qafLfqbNbFs7MnduplWbtGdHoH2rhuBGrtyxjgDj+W2r/Fw8XmhTKiF5 R4uaFL0AAgF2VgciMGOIGnPUWryr2erL41i/iFm/TRCFB4lxAhKRoGXPAwJMiXyOAUyl R70jz5uaI/8j1pOzpDgfIfOMA/HIjdIOyCx1Iim/MFFLyjXglbpB5fyLA/AARZtEL9E7 SZda84P4P2YHzPZNzeaRS8pVyFpDXIIGnzciQFHEbRGs6A68x/xUawHEyUueNiV1y/bh oxZh0W9Dh1Heu7/jWPbeFxITgB5Y5G+zgXTleoshsZIQOWaLVcBm1LDiXErszOnswZtq YojQ==
X-Received: by 10.49.71.38 with SMTP id r6mr34703691qeu.30.1373635635767; Fri, 12 Jul 2013 06:27:15 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:4d2:4fa1:1c00:b229? ([2001:420:2481:20:4d2:4fa1:1c00:b229]) by mx.google.com with ESMTPSA id w9sm30289992qas.8.2013.07.12.06.27.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 06:27:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113030D0BE@GAALPA1MSGUSR9L.ITServices.sbc.com>
Date: Fri, 12 Jul 2013 09:27:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A07EF6B-03C4-4D89-94C0-287CD9C8892F@gmail.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <2D09D61DDFA73D4C884805CC7865E6113030D0BE@GAALPA1MSGUSR9L.ITServices.sbc.com>
To: "STARK, BARBARA H" , "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 13:27:20 -0000

On Jul 12, 2013, at 9:24 AM 7/12/13, "STARK, BARBARA H"  =
wrote:

>> Perhaps we can just drop the idea of the options altogether.  They =
will only
>> be of value in devices that also use default SOLMAXRT =3D=3D 3600.  =
Is changing
>> the default enough to skate us past this transition case?
>=20
> I don't see the options as necessary to the problem we're trying to =
solve and would not object to dropping them.
> Barbara

Thanks, Barbara.

Might be good to hear from other operators (customers!) as well.  OK, so =
predicting the future is hard, but I'll ask anyway - do we anticipate =
another use case for this option beyond the immediate use case of an =
IPv6 deployment where some, but not all, devices will be granted IPv6 =
service via DHCPv6?

- Ralph


From tomasz.mrugalski@gmail.com  Fri Jul 12 06:43: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 741A921F9BA0 for ; Fri, 12 Jul 2013 06:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level: 
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjDWMsl6Vcyc for ; Fri, 12 Jul 2013 06:43:19 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3500321F9F29 for ; Fri, 12 Jul 2013 06:43:19 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id d7so3749584bkh.39 for ; Fri, 12 Jul 2013 06:43:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=X8RQRp35aNO+ObXeKHaV4zH3RrQY+DW7QF6JOmHwHiY=; b=C8qHoaHaLQfOzBC3hB+isuGte0e9o7PjbFADMnqbRdvNdnR5Q0TTBKCItbdfM4o8xz al2htEM0GIA8GdeyP8+6NQ+3pGviRQB0V491U980DpuSavBTHtkDaDp0+TpDa3+g701V cg5L+/is0HSs57KvlYtKcUt7GRLH1OcM/5MM1ORMK/DHrsMXSAxalIayyhkGOM9YMG2B lJCBE0lYm1yDeblP5PyHKII9AtrkG65k0GbczrZOpYpXLxZLHh0lUbEG/nL3zD9YlKQo fIjhU/keVku0NGXQoA7Zjv4M2fShx/4vu9aogUyr1/HJAdRaQbz0oAwIDEBh2YAkItQZ JJDQ==
X-Received: by 10.204.54.137 with SMTP id q9mr6322139bkg.80.1373636596261; Fri, 12 Jul 2013 06:43:16 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id g5sm1343274bkh.17.2013.07.12.06.43.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 06:43:15 -0700 (PDT)
Message-ID: <51E007ED.7010105@gmail.com>
Date: Fri, 12 Jul 2013 15:43:09 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ralph Droms 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
In-Reply-To: <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130712154309824
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 13:43:20 -0000

On 12.07.2013 14:54, Ralph Droms wrote:
>> The main reason for this was to handle situation where server
>> didn't give addresses to client - thus just a Solicit/Advertise
>> cycle (client has nothing to Request, so no Reply).
That wouldn't be enough. If you want to limit DHCPv6 traffic in your
network, you'll also need to handle INF-REQUEST.

> Ah, right, of course.
> 
>> 
>> But because default has changed (120 -> 3600), it will reduce rate
>> of Solicits. Might have been nice if server (via Advertise) could
>> increase value further (1 day...).
>> 
>> If you thus just do this on the Reply, the utility of SOLMAX option
>> is really lost.
> 
> Agreed.
> 
> But I'm concerned that we're letting the perfect be the enemy of the
> good in what should be a really simple use case.
> 
> Perhaps we can just drop the idea of the options altogether.  They
> will only be of value in devices that also use default SOLMAXRT ==
> 3600.  Is changing the default enough to skate us past this
> transition case?
But the 3600 value was a judgement call. Some people may argue that 120
is a better value while other prefer 86400.

I think the approach with changing the value to 3600 and having those
options is a good one. It alleviates the problem and provide means to
fine tune if the default solution is not sufficient.

Here's my attempt to summarize all 3 possible solutions:

1. Change timer values only, no options
+ very short draft, easy to implement
- 3600 was an arbitrary chosen value. Some time in the future people may
  argue that it is too high/too low and may try to update it again, so
  it doesn't solve the the problem definitely.
- lack the flexibility for sysadmins to fine tune to their specific
  needs. (You want super fast recovery after server failure? set it to
  10. You plan to deploy IPv6 sometime in late 2020s? Set it to 86400
  or larger)

2. Allow options in Advertise and Reply:
+ you know which clients are updated and which are legacy (SOLMAXRT
  present in ORO or not)
+ flexibility to fine tune to specific networks
+ ability to deploy dummy server to send back NoAddrsAvail + SOLMAXRT
  to Solicits and Reply with INFMAXRT to inf-requests.
- you change how clients process options in advertise. Up to now, no
  option from advertise is ever consumed by the client, it is merely
  used to pick the most suitable server. Updating clients code for
  using that one specific option also in advertise will be difficult in
  some cases
- you get a solution that is less resistant to configuration errors or
  rogue servers. In both cases you may get different SOLMAXRT values in
  different Advertises. What's worse, the clients behavior will be
  dependent on the order in which Advertises were received. It also may
  vary between clients.
- if you allow Advertise, a bad guy can deploy rogue DHCPv6 server in
  IPv4-only networks (lots of them are still around), set SOLMAXRT to 1
  and enjoy his easy to pull off DDOS. What's worse, his rogue server
  could then disappear, but the DDOS would continue. (In a typical case
  a rogue DHCPv6 server in IPv4-only network can mess things up in many
  different ways, I admit. However, there are solutions that allow
  trust relationship between clients and a server.)
- the language in the text and the code implementing it would be tricky.
  It would have to say something like "client picks the value from that
  ADVERTISE that it would have picked if the ADVERTISE had addresses".
- lack of accountability. Clients won't really know who told them to
  use very low SOLMAXRT as the text says that every SOLMAXRT from every
  Advertise must be used. Implementors will likely not log the servers
  DUID, IP or MAC address.

3. Allow options in Reply only:
+ you know which clients are updated and which are legacy (SOLMAXRT
  present in ORO or not)
- dummy server would be less functional (it would handle inf-requests
  ok, but not Solicits that are more popular)
+ the confidence that you use data from a server you chose.
+ consistency between clients (each will have SOLMAXRT and INFMAXRT set
  to the same value in case of configuration issues or rogue servers)
+ flexibility to fine tune to specific networks
+ very easy to implement
+ simpler draft text than in #2
- more complex draft text than in #1

I really think that allowing SOLMAXRT and INFMAXRT options in Reply only
is the best way forward. It loses a bit on deploying dummy server, but I
think it is not that relevant. Clients that are able to handle SOLMAXRT
option are already using 3600 timer. Otherwise it has all benefits. My
preference is #3. If that is not acceptable, #1 would the next best
choice for me. I don't like #2, because it opens up too many abuse
options and is too tricky to implement.

Tomek

From volz@cisco.com  Fri Jul 12 06:43: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 57BA411E8127 for ; Fri, 12 Jul 2013 06:43:28 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgqc0FCNjlpK for ; Fri, 12 Jul 2013 06:43:23 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB5F11E8128 for ; Fri, 12 Jul 2013 06:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2440; q=dns/txt; s=iport; t=1373636603; x=1374846203; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TY8bch4x42QcLgWay4+5Dr64e2Aux5Fl0SDwd1IaH9k=; b=iFRxwrYZTOerTgU5esDTigTWhL9lYqgk5PiQXkqGWfja891hzskoUSMx gACFo1GkfI72ALaR3WS7l5oLhALIlItsVfxEhqxknQLHQtIiVW1dLHibJ V9z9i02i9qJPD0haOYdmSC81bMAdDJqPe24KakKUqlMXhmC+SgzrXgYjP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAH4H4FGtJV2c/2dsb2JhbABagwY0wiCBCRZ0giMBAQEDAQEBATc0CxACAQgOCh4QIQYLJQIEDgWHfQMJBgyuPw2IWgSMeII2MweDC2wDlXOBaYwnhSaBWYE5
X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234046773"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jul 2013 13:43:23 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6CDhMh0027785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 13:43:22 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 08:43:21 -0500
From: "Bernie Volz (volz)" 
To: Ralph Droms 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfv74C2mZ4sLtA0SzmbFVE+f0XZlhXAMAgAAA2QD//7CyVg==
Date: Fri, 12 Jul 2013 13:43:21 +0000
Message-ID: 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <2D09D61DDFA73D4C884805CC7865E6113030D0BE@GAALPA1MSGUSR9L.ITServices.sbc.com>, <2A07EF6B-03C4-4D89-94C0-287CD9C8892F@gmail.com>
In-Reply-To: <2A07EF6B-03C4-4D89-94C0-287CD9C8892F@gmail.com>
Accept-Language: en-US
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
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -	respond by July 4
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, 12 Jul 2013 13:43:28 -0000

Ralph ... I think the options should not be removed so hastily. For a netwo=
rk where service is expected, sending the 120 second value to override the =
3600 is really important (and this could be in the Reply).

If a server provider has a maintenance window where service isn't available=
 for a period, clients may then not retry but once every hour and thus may =
not have internet service or voice service for a long time. Yes, this won't=
 help those clients that didn't previously communicate with the server (sin=
ce the last boot) to get the shorter time. And cases where it would apply m=
ight be minimal with long lease times, but think of failover and MCLT restr=
ictions - clients getting a "new" lease before the window would have had sh=
orter MCLT lease times and could easily have returned to sending Solicits.

I think it could be a mistake to remove the options - not for the case to s=
low down retransmissions as the shift from changing the default from 120 to=
 3600 will improve that situtation, but in the cases where you want clients=
 to use the original 120 (or shorter?) value to address the situation above=
.

I think this maintenance window issue may also be something that SPs haven'=
t given careful consideration to as extending the window by an hour for som=
e clients may have to be factored in.

- Bernie (from iPad)

On Jul 12, 2013, at 9:27 AM, "Ralph Droms"  wrote:

>=20
> On Jul 12, 2013, at 9:24 AM 7/12/13, "STARK, BARBARA H"  =
wrote:
>=20
>>> Perhaps we can just drop the idea of the options altogether.  They will=
 only
>>> be of value in devices that also use default SOLMAXRT =3D=3D 3600.  Is =
changing
>>> the default enough to skate us past this transition case?
>>=20
>> I don't see the options as necessary to the problem we're trying to solv=
e and would not object to dropping them.
>> Barbara
>=20
> Thanks, Barbara.
>=20
> Might be good to hear from other operators (customers!) as well.  OK, so =
predicting the future is hard, but I'll ask anyway - do we anticipate anoth=
er use case for this option beyond the immediate use case of an IPv6 deploy=
ment where some, but not all, devices will be granted IPv6 service via DHCP=
v6?
>=20
> - Ralph
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

From rdroms.ietf@gmail.com  Fri Jul 12 06:52: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 72DE311E810A for ; Fri, 12 Jul 2013 06:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smH9a5AUzZcS for ; Fri, 12 Jul 2013 06:52:11 -0700 (PDT)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5E911E80FE for ; Fri, 12 Jul 2013 06:52:09 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id n1so4939407qcx.36 for ; Fri, 12 Jul 2013 06:52:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=o5DhsgPB8uHugGcZGy3ofz8mngElYhofhkAz09A7ce8=; b=rP+8vt173XGE1KhR4/JBcY/9L6ZpWN2fpOIotI5v7V9m4b9io8YtrJRbgnpPHADrcp TGXH5nN1eXwGxzXHQGkDWDl4faJb96Q9GXC/jNXB317aRvJeLEojiTK4xnGt6Ldi3wkJ MeqRjqhqWVPb2nzJxsdzHvBHqUJJgKo0Kt2oawovtgYqKwwJgFrFxvbH2OT1pz4GryNK 7zGKn280K019HsdngEy8Kg/x9BmBYbf0DXd9IdayrjT1jb1ok7/jhQtE38Zn2EBkRV/i Px8VbuBRffRZ5Kxr+sSVGc43162za5PDpNZT+k68B7zq3V7vjtC1eFSY2TPor4B8YaNj H5bg==
X-Received: by 10.224.73.193 with SMTP id r1mr30249975qaj.57.1373637129490; Fri, 12 Jul 2013 06:52:09 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:4d2:4fa1:1c00:b229? ([2001:420:2481:20:4d2:4fa1:1c00:b229]) by mx.google.com with ESMTPSA id r10sm33777931qeu.4.2013.07.12.06.52.07 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 06:52:08 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <51E007ED.7010105@gmail.com>
Date: Fri, 12 Jul 2013 09:52:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com>
To: Tomek Mrugalski 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 13:52:12 -0000

Tomek - how does #3 handle the case in which no Reply is sent, such as =
the original use case in which no IPv6 addresses will be assigned (or =
prefixes delegated)?

I can imagine a bit of hackery in which the server returns an Advertise =
with addresses, but then returns a Reply with NoAddrsAvail.

Otherwise, the option won't be useful in the original use case.  It =
might be useful in other use cases.

- Ralph

On Jul 12, 2013, at 9:43 AM 7/12/13, Tomek Mrugalski =
 wrote:

> On 12.07.2013 14:54, Ralph Droms wrote:
>>> The main reason for this was to handle situation where server
>>> didn't give addresses to client - thus just a Solicit/Advertise
>>> cycle (client has nothing to Request, so no Reply).
> That wouldn't be enough. If you want to limit DHCPv6 traffic in your
> network, you'll also need to handle INF-REQUEST.
>=20
>> Ah, right, of course.
>>=20
>>>=20
>>> But because default has changed (120 -> 3600), it will reduce rate
>>> of Solicits. Might have been nice if server (via Advertise) could
>>> increase value further (1 day...).
>>>=20
>>> If you thus just do this on the Reply, the utility of SOLMAX option
>>> is really lost.
>>=20
>> Agreed.
>>=20
>> But I'm concerned that we're letting the perfect be the enemy of the
>> good in what should be a really simple use case.
>>=20
>> Perhaps we can just drop the idea of the options altogether.  They
>> will only be of value in devices that also use default SOLMAXRT =3D=3D
>> 3600.  Is changing the default enough to skate us past this
>> transition case?
> But the 3600 value was a judgement call. Some people may argue that =
120
> is a better value while other prefer 86400.
>=20
> I think the approach with changing the value to 3600 and having those
> options is a good one. It alleviates the problem and provide means to
> fine tune if the default solution is not sufficient.
>=20
> Here's my attempt to summarize all 3 possible solutions:
>=20
> 1. Change timer values only, no options
> + very short draft, easy to implement
> - 3600 was an arbitrary chosen value. Some time in the future people =
may
>  argue that it is too high/too low and may try to update it again, so
>  it doesn't solve the the problem definitely.
> - lack the flexibility for sysadmins to fine tune to their specific
>  needs. (You want super fast recovery after server failure? set it to
>  10. You plan to deploy IPv6 sometime in late 2020s? Set it to 86400
>  or larger)
>=20
> 2. Allow options in Advertise and Reply:
> + you know which clients are updated and which are legacy (SOLMAXRT
>  present in ORO or not)
> + flexibility to fine tune to specific networks
> + ability to deploy dummy server to send back NoAddrsAvail + SOLMAXRT
>  to Solicits and Reply with INFMAXRT to inf-requests.
> - you change how clients process options in advertise. Up to now, no
>  option from advertise is ever consumed by the client, it is merely
>  used to pick the most suitable server. Updating clients code for
>  using that one specific option also in advertise will be difficult in
>  some cases
> - you get a solution that is less resistant to configuration errors or
>  rogue servers. In both cases you may get different SOLMAXRT values in
>  different Advertises. What's worse, the clients behavior will be
>  dependent on the order in which Advertises were received. It also may
>  vary between clients.
> - if you allow Advertise, a bad guy can deploy rogue DHCPv6 server in
>  IPv4-only networks (lots of them are still around), set SOLMAXRT to 1
>  and enjoy his easy to pull off DDOS. What's worse, his rogue server
>  could then disappear, but the DDOS would continue. (In a typical case
>  a rogue DHCPv6 server in IPv4-only network can mess things up in many
>  different ways, I admit. However, there are solutions that allow
>  trust relationship between clients and a server.)
> - the language in the text and the code implementing it would be =
tricky.
>  It would have to say something like "client picks the value from that
>  ADVERTISE that it would have picked if the ADVERTISE had addresses".
> - lack of accountability. Clients won't really know who told them to
>  use very low SOLMAXRT as the text says that every SOLMAXRT from every
>  Advertise must be used. Implementors will likely not log the servers
>  DUID, IP or MAC address.
>=20
> 3. Allow options in Reply only:
> + you know which clients are updated and which are legacy (SOLMAXRT
>  present in ORO or not)
> - dummy server would be less functional (it would handle inf-requests
>  ok, but not Solicits that are more popular)
> + the confidence that you use data from a server you chose.
> + consistency between clients (each will have SOLMAXRT and INFMAXRT =
set
>  to the same value in case of configuration issues or rogue servers)
> + flexibility to fine tune to specific networks
> + very easy to implement
> + simpler draft text than in #2
> - more complex draft text than in #1
>=20
> I really think that allowing SOLMAXRT and INFMAXRT options in Reply =
only
> is the best way forward. It loses a bit on deploying dummy server, but =
I
> think it is not that relevant. Clients that are able to handle =
SOLMAXRT
> option are already using 3600 timer. Otherwise it has all benefits. My
> preference is #3. If that is not acceptable, #1 would the next best
> choice for me. I don't like #2, because it opens up too many abuse
> options and is too tricky to implement.
>=20
> Tomek


From volz@cisco.com  Fri Jul 12 07:13: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 4B9CE21E805E for ; Fri, 12 Jul 2013 07:13:51 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FziqzP47LI5G for ; Fri, 12 Jul 2013 07:13:46 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6520B21F9A48 for ; Fri, 12 Jul 2013 07:13:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2806; q=dns/txt; s=iport; t=1373638426; x=1374848026; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=PHjd/SMrzyMvOi+lkfGCQJ8gmrZWQnHqnwgOFUT1RfM=; b=kKSOFIAk4W5Ljvpn1JK3y09pW/yl8y3l7Ln0Ew2h9W1HGwzjnMLloOZd PJxBz+cjs5tbQkPlrGNA4sBEbcSL8j2jgBX5fOKrpv40uvDM2x+1CPGdi Yx3VRDrdTnR/pvjIUp5A5IwZdFY2tbBQEjmIvWvQo8L6StA0jGvlNLGsF s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAH8O4FGtJXG9/2dsb2JhbABagwY0T8FRgQkWdIIjAQEBAwEBAQEaHTQLBQcGAQgOAwQBAQsUCS4LFAkJAQQOBQiIAQYMtyaPMDENgwVsA5kFkCSDEoIo
X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234058267"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jul 2013 14:13:46 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6CEDj03014717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 14:13:45 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 09:13:45 -0500
From: "Bernie Volz (volz)" 
To: Ralph Droms 
Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respond by July 15
Thread-Index: Ac5/CeXs+iBdFB2RQ1KzXVvxbBOdyQ==
Date: Fri, 12 Jul 2013 14:13:43 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185E06E8@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.86.255.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respond by July 15
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, 12 Jul 2013 14:13:51 -0000

Fragment type is one of the 'basic' option formats in section 5. You can pu=
t these together to build new options that still meet the requirements (tho=
ugh in some cases that requires additional length fields). Perhaps this is =
one area that needs a bit more clarity? (I think I would have said one can =
build structured options using the basic option formats in section 5 as the=
 data elements, perhaps with additional (2-octet) length fields where appro=
priate.)

Yes, RFC 2131 (and perhaps 2132) should be in the Informative References as=
 "DHCPv4" is mentioned several times. First of these (at least) should be l=
inked to the reference (looks to be in section 9).

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R=
alph Droms
Sent: Thursday, July 11, 2013 3:56 PM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respond b=
y July 15

Looks about ready to publish.  Some comments:

Title of section 10: "Additional States Considered Harmful"  I suggest s/St=
ates/State/.  At first, I thought this referred to client states as in DHCP=
v4.  The text in section 10 clearly refers to state added to the various ki=
nds of state the server maintains to manage clients.

In section 13, what is a "fragment type"?  The word fragment appears (once)=
 previously in section 5, but I don't have a clue what a "fragment type" mi=
ght be.

Add citations to RFC 2131 and RFC 2132 for the references to DHCPv4?

- Ralph

On Jul 1, 2013, at 5:44 PM 7/1/13, Bernie Volz (volz)  wrot=
e:

> The draft-ietf-dhc-option-guidelines-12, http://tools.ietf.org/html/draft=
-ietf-dhc-option-guidelines-12, addresses the comments from the previous (-=
11) last call. While originally I expected to have a short (1 week) last ca=
ll for the updated document, I think it best to have the standard 2 weeks g=
iven the time of year (and the Independence Day holiday in the US).
> =20
> Please review the draft and indicate whether or not you feel this version=
 is ready to be published. Your response matters to the process, so please =
do respond.
> =20
> Do note: While I encourage full reviews, the main focus is to assure we h=
ave consensus on the recent changes from the -11. The -11 WGLC support will=
 be taken into consideration.
> =20
> As Tomek is an author, I will evaluate consensus after July 15, 2013.
> =20
> -          Bernie
> =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

From jason.weil@twcable.com  Fri Jul 12 07:35:07 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 33DB521E808A for ; Fri, 12 Jul 2013 07:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.963
X-Spam-Level: 
X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUaRBFwfvbzG for ; Fri, 12 Jul 2013 07:35:03 -0700 (PDT)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5979021E805E for ; Fri, 12 Jul 2013 07:35:00 -0700 (PDT)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.89,653,1367985600"; d="scan'208";a="27020308"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Jul 2013 10:34:43 -0400
Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 12 Jul 2013 10:34:59 -0400
From: "Weil, Jason" 
To: "STARK, BARBARA H" , Ralph Droms ,  "Bernie Volz (volz)" 
Date: Fri, 12 Jul 2013 10:35:01 -0400
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: Ac5/DPx7FC7+uN/fRW+ialR1/J44zA==
Message-ID: 
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113030D0BE@GAALPA1MSGUSR9L.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.4.130416
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 14:35:07 -0000

I'm leaning towards Barbara on this one. The options do give more
flexibility for those admins who find benefit, but they don't feel
critical to the original problem statement. We could always split this
work into two drafts and use this draft to make the necessary default
timer changes. If the options are deemed beneficial to members of the WG a
separate draft would allow more time for testing and analysis on their
impact.

Jason

On 7/12/13 9:24 AM, "STARK, BARBARA H"  wrote:

>> Perhaps we can just drop the idea of the options altogether.  They will
>>only
>> be of value in devices that also use default SOLMAXRT =3D=3D 3600.  Is
>>changing
>> the default enough to skate us past this transition case?
>
>I don't see the options as necessary to the problem we're trying to solve
>and would not object to dropping them.
>Barbara
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From tomasz.mrugalski@gmail.com  Fri Jul 12 08:01:04 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 198A621F9477 for ; Fri, 12 Jul 2013 08:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.317
X-Spam-Level: 
X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-1Qq9T+S6Oe for ; Fri, 12 Jul 2013 08:01:03 -0700 (PDT)
Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 486F721F944F for ; Fri, 12 Jul 2013 08:01:03 -0700 (PDT)
Received: by mail-bk0-f41.google.com with SMTP id jc3so3853599bkc.14 for ; Fri, 12 Jul 2013 08:01:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=9NhDoi/d6tQ2AdaeAL1V6TJ/Iz7QjtkDj1y8zSfVOAs=; b=AEFkTuJnpdG4aVRYG+BxtyM0icvs3lc8bDnQoey/RniDn2nnBqLyQ4BWFFP+pAYfCE Ap1y398xtGfd+NaZi7/pIO8WxT46De1GKII4KuoghX/R0GtNNqu4HVPL+89e/2RTo1vv LBioeZb+g1ufUvmOIbwPGINzRlpqoAMqTnBdmUuhpxrQf4OcZP+WRO/+7te7G/r2CMH2 Sp5Kmi837j/zfn2bxpZADCP0K189H0BjtiNm+qi+p3mCBU1ucTUeibbQP98qRBVzNyfH lgt0627cVcWlwPmkNwYfhBf0Xm+phDSqv/WIrytdDBmsJBaL88/xJpU/izibSmZbzvK6 D37g==
X-Received: by 10.204.186.70 with SMTP id cr6mr6199436bkb.177.1373641261966; Fri, 12 Jul 2013 08:01:01 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id g5sm1411109bkh.17.2013.07.12.08.00.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 08:01:01 -0700 (PDT)
Message-ID: <51E01A27.1040409@gmail.com>
Date: Fri, 12 Jul 2013 17:00:55 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ralph Droms 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com>
In-Reply-To: <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130712170055411
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 15:01:04 -0000

On 12.07.2013 15:52, Ralph Droms wrote:
> Tomek - how does #3 handle the case in which no Reply is sent, such
> as the original use case in which no IPv6 addresses will be assigned
> (or prefixes delegated)?
It doesn't for stateful clients. If the client is modified, it will
stick to 3600, so the original problem is alleviated, we just lose the
ability to tweak it. If the client is legacy, it won't request SOLMAXRT
in the first place. For stateless clients it would work ok (reply sent
in response to inf-request). I admit that majority of clients are
stateful, though.

> I can imagine a bit of hackery in which the server returns an
> Advertise with addresses, but then returns a Reply with
> NoAddrsAvail.
That's certainly possible. But I think that the original use case
(setting up a dummy server to tell clients that dhcpv6 is not there, so
they should try less often) is not that important. Modified clients will
send 1 packet every hour anyway and legacy clients once every 2 minutes.
More important case is what Bernie metioned: you have functional
network, but need to bring down your DHCPv6 infrastructure for
maintenance and want to prepare them for it. In that case the reply only
(#3) would work.

> Otherwise, the option won't be useful in the original use case.  It
> might be useful in other use cases.

If we leaning toward #2 (advertise and reply), I insist on limiting the
range of allowed values (both min and max) to prevent or at least limit
abuses.

Tomek


From rdroms.ietf@gmail.com  Fri Jul 12 08:24: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 F0B8721E80A7 for ; Fri, 12 Jul 2013 08:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.443
X-Spam-Level: 
X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk5x5w569VZw for ; Fri, 12 Jul 2013 08:23:55 -0700 (PDT)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2C21E80AF for ; Fri, 12 Jul 2013 08:23:45 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id e11so5017293qcx.38 for ; Fri, 12 Jul 2013 08:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=oCsrqGIknHRH+ABv4G34Xp5jwJ0cAlNgheU1B31Ci6Y=; b=0MEmHLgxzTMZoxMnUhRzDEvSnenmCLt6UvRqogwsiF7491n8iwIAtakEucLsjm6BVG CNatkQWtz7j4Q7Wh9GYYw3nWvPETIAY6LT+uH4h3HTDqIXzelLNt4sIgD5BIi28qdUWI Xs9126cpUFIUuqxE0k+8vPBv5wbIHUoDZy9udi5AuPfRUPhNi6LbFkgn19uB242penl+ 6TMLat5jnsXlf065bN3kzBQxuNrLwdF+uvIKSlBc/AYBa29NR2q/uV2YJ0AM8FB8KZCB 6wgWer1fdDkBi1y9DRqlAyGDHG7KZa3FuFpWMiq3hxZ2ZdRJ71PfyVtTwa6V4LVwKZlw 7JTQ==
X-Received: by 10.49.71.141 with SMTP id v13mr35980455qeu.36.1373642625213; Fri, 12 Jul 2013 08:23:45 -0700 (PDT)
Received: from ?IPv6:2001:420:2481:20:4d2:4fa1:1c00:b229? ([2001:420:2481:20:4d2:4fa1:1c00:b229]) by mx.google.com with ESMTPSA id l4sm35351358qay.0.2013.07.12.08.23.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 08:23:44 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <51E01A27.1040409@gmail.com>
Date: Fri, 12 Jul 2013 11:23:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>
To: Tomek Mrugalski , "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 15:24:05 -0000

On Jul 12, 2013, at 11:00 AM 7/12/13, Tomek Mrugalski =
 wrote:

> On 12.07.2013 15:52, Ralph Droms wrote:
>> Tomek - how does #3 handle the case in which no Reply is sent, such
>> as the original use case in which no IPv6 addresses will be assigned
>> (or prefixes delegated)?
> It doesn't for stateful clients. If the client is modified, it will
> stick to 3600, so the original problem is alleviated, we just lose the
> ability to tweak it. If the client is legacy, it won't request =
SOLMAXRT
> in the first place. For stateless clients it would work ok (reply sent
> in response to inf-request). I admit that majority of clients are
> stateful, though.

And we've gotten feedback from a couple of customers that just setting =
*_MAX_RT to 3600 should be sufficient.

>=20
>> I can imagine a bit of hackery in which the server returns an
>> Advertise with addresses, but then returns a Reply with
>> NoAddrsAvail.
> That's certainly possible. But I think that the original use case
> (setting up a dummy server to tell clients that dhcpv6 is not there, =
so
> they should try less often) is not that important.

Ok.  But we don't have any other requested use case beyond the original =
one, in which a server is configured to Advertise addresses to some =
clients but not others.

In my opinion, any other use case, in which all clients are denied =
DHCPv6 address assignment, can be more conveniently managed by turning =
off the DHCPv6 relay, dropping the DHCPv6 messages in the relaying =
router, etc.  The only problematic case is when some, but not all, =
clients are granted DHCPv6 addresses.

> Modified clients will
> send 1 packet every hour anyway and legacy clients once every 2 =
minutes.
> More important case is what Bernie metioned: you have functional
> network, but need to bring down your DHCPv6 infrastructure for
> maintenance and want to prepare them for it. In that case the reply =
only
> (#3) would work.

Or just turn off the relay.  My understanding is the problem arises when =
millions of Solicits are aggregated at a DHCPv6 server, not when =
thousands are received by a relay.

>=20
>> Otherwise, the option won't be useful in the original use case.  It
>> might be useful in other use cases.
>=20
> If we leaning toward #2 (advertise and reply), I insist on limiting =
the
> range of allowed values (both min and max) to prevent or at least =
limit
> abuses.
>=20
> Tomek

- Ralph

>=20


From rdroms.ietf@gmail.com  Fri Jul 12 08:26: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 3474921F8D0D for ; Fri, 12 Jul 2013 08:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.643
X-Spam-Level: 
X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KS2atF4NfrZ for ; Fri, 12 Jul 2013 08:26:38 -0700 (PDT)
Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E683721F99F4 for ; Fri, 12 Jul 2013 08:26:05 -0700 (PDT)
Received: by mail-qe0-f41.google.com with SMTP id b4so5253865qen.28 for ; Fri, 12 Jul 2013 08:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FPYqH4ecfGWLkg0Ly9QsUtWf/Jf96ke6UpOaHHOzLGI=; b=W39FP0bTSPWbV3CAes3bISe/cYQpVpEsVCoNNwSIWrpv6Q5slq/aW+93dsWDfTwBwG kJI+aVrKNPt0/GaiD/X7sCVOFOsdcBxoLL9J330VnBgQusS1gEeK3o7UuWtxITfNSKP8 ahcESA94ZKL9UN4ezXAdra0VM06QKnVVf8y7yFdxJfQXtVVB8vCT7yLse3uAy8af6eI/ chC8hrK1w99I/conxjgKY65gBaihEMacSznQYPLKvyL5BhYLghxjia45CojxRAaJCzkZ bmXQUBbZZzqbK5eVLMs7aseHz5a/nZZtRFJR9mI+1mp7mCaTrolRp401ym7jRMqNAtA1 UgUg==
X-Received: by 10.229.148.6 with SMTP id n6mr8438908qcv.108.1373642765444; Fri, 12 Jul 2013 08:26:05 -0700 (PDT)
Received: from rtp-rdroms-8919.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id l4sm35363258qay.0.2013.07.12.08.26.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 08:26:04 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <51E01A27.1040409@gmail.com>
Date: Fri, 12 Jul 2013 11:26:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>
To: Tomek Mrugalski , "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 15:26:39 -0000

Just to be clear, in my opinion we could write a spec for the options =
that might provide some additional capabilities.  Do those additional =
capabilities address a useful problem and are we sure the design doesn't =
add implementation and operational risks?

- Ralph


From volz@cisco.com  Fri Jul 12 08:48:53 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 3652921F9DFB for ; Fri, 12 Jul 2013 08:48:53 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf0gY3kfPIvc for ; Fri, 12 Jul 2013 08:48:47 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A857921F9E79 for ; Fri, 12 Jul 2013 08:48:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1133; q=dns/txt; s=iport; t=1373644127; x=1374853727; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZyzDHhvpnCA30VgprBcxUiXj/HKttGV1+EVWQf+UGJA=; b=VZBfFsn3UcxUS8Cq2ePxBSy65TTfzqH0x3emuUe/RgRYdy/JI3I1krQZ 0HXzMTxHXnHlJ2wersEwNgLHqxCgwp5g3pEGMzmpMlKYn9gdtRTwK8dML zhzQIXhEEGftpg7Bt9o//LbdB6YiIH2od6LEAy5UO6SppxZ1FBOjwjAau E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFABIk4FGtJXG//2dsb2JhbABagwaBA8FRgQkWdIIjAQEBBDo/DAQCAQgOAwQBAQsUCQchERQJCAIEAQ0FCId1Aw+ufg2IXox4gTKBBjEHBoMFbAOVc44QhSaBWYE5gWk/
X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="231102392"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jul 2013 15:48:47 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6CFmlp6028990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 15:48:47 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 10:48:46 -0500
From: "Bernie Volz (volz)" 
To: Ralph Droms , Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfxCbNsz9QllL4k6dStCNj7Oo55lhfeuA//+x4KA=
Date: Fri, 12 Jul 2013 15:48:46 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.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.255.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 15:48:53 -0000

I think if there was text to limit the SOLMAX (and INF) option value to be =
120 seconds to 1 day (24 hours), we could leave the options in place (and l=
et the client use the values from Advertise messages). That would avoid rea=
lly bad values and still give the possibility to set the value back to 120 =
for those cases where valid service is expected.

I'm not sure removing the options is the best avenue - as it provides no wa=
y to 'correct' any problems that might occur if the 3600 seconds turns out =
to have negative operational consequences.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20
Sent: Friday, July 12, 2013 11:26 AM
To: Tomek Mrugalski; Bernie Volz (volz)
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - res=
pond by July 4

Just to be clear, in my opinion we could write a spec for the options that =
might provide some additional capabilities.  Do those additional capabiliti=
es address a useful problem and are we sure the design doesn't add implemen=
tation and operational risks?

- Ralph


From tomasz.mrugalski@gmail.com  Fri Jul 12 09:34:26 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 80ECC21F9F02 for ; Fri, 12 Jul 2013 09:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.341
X-Spam-Level: 
X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B7v4iuBHqUU for ; Fri, 12 Jul 2013 09:34:26 -0700 (PDT)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D275021F9E5B for ; Fri, 12 Jul 2013 09:34:25 -0700 (PDT)
Received: by mail-bk0-f48.google.com with SMTP id jf17so3822257bkc.21 for ; Fri, 12 Jul 2013 09:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=1jqHVNk7/c3Y5L7eR0pZ85gDAYUWtDp5zb5Ic4w5oqg=; b=r4ZenviVH0GFuFT7gKvjXz5/SBvk4H/KUCWsjHpqVJn1ajUWr7LVuTO9GueAPNxqrE KgkMDmgm98f6qirc3OH/+vFN78GsPWev1DHspHFyHTVAbTqnQJRcQIL8Xk1dg/UTe2GH HbeNBcfXkG3+7RTRzSQmKmDhEQ+D1BDPIK7qi+dmaRLpBU3BztO0C8tmRLwszwvK7sO9 W+4dvdCDN1HNmWrsShRbt6zsDMdCM0rx4lVZTmaH1KDISwX1boGFYSzPi0dBqZRfcD8P ZMfMuTGtNdAVosRE2ZlFKG5PhA74sgmusUV+revywlq8uENlPuqKMr03FrQ3KPKZ+zD5 V7XQ==
X-Received: by 10.204.240.202 with SMTP id lb10mr6605888bkb.134.1373646864890;  Fri, 12 Jul 2013 09:34:24 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id px7sm9380767bkb.9.2013.07.12.09.34.22 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 09:34:23 -0700 (PDT)
Message-ID: <51E0300A.4000303@gmail.com>
Date: Fri, 12 Jul 2013 18:34:18 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "dhcwg@ietf.org WG" 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>  <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130712183418589
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "Bernie Volz \(volz\)" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 12 Jul 2013 16:34:26 -0000

On 12.07.2013 17:48, Bernie Volz (volz) wrote:
> I think if there was text to limit the SOLMAX (and INF) option value
> to be 120 seconds to 1 day (24 hours), we could leave the options in
> place (and let the client use the values from Advertise messages).
> That would avoid really bad values and still give the possibility to
> set the value back to 120 for those cases where valid service is
> expected.
I like this. With those lower and upper bounds, the solution #2 (have it
in advertise as the text specifies now) would be ok.

> I'm not sure removing the options is the best avenue - as it provides
> no way to 'correct' any problems that might occur if the 3600 seconds
> turns out to have negative operational consequences.
Good point.

Tomek

From volz@cisco.com  Fri Jul 12 09:35:07 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 691F021F9E5B for ; Fri, 12 Jul 2013 09:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.568
X-Spam-Level: 
X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daTTyl8lmMFW for ; Fri, 12 Jul 2013 09:35:02 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD5021F9F10 for ; Fri, 12 Jul 2013 09:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14635; q=dns/txt; s=iport; t=1373646902; x=1374856502; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=muUuEaEG4VYiGCYGhME8jstS8B/0e4U3EORBucXFBwU=; b=aOAYbEhngt0M59d1R2yk267FUkCYY3RXFwVHBg67f649m9+2FeWfBCYr THwU9Z0GSaRciPgRVDepRHsrBIrdHMArevSSjJVBeL1NGjp0t8bd4AL8T p/BnVgNkHqlAS83lpLMVgyHexLXFVHkdk/emWU/B+qitqLQarpgNC6jkH 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAFEv4FGtJV2d/2dsb2JhbABagkJENE+5HogygQsWdIIjAQEBBAEBASpBCxACAQgRBAEBCx0HJwsUCQgBAQQOBQgBiAYMt2uOH4ERLQQGAYMLbAOZBZAkgVmBOYFxNw
X-IronPort-AV: E=Sophos;i="4.89,654,1367971200";  d="scan'208,217";a="234130457"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jul 2013 16:35:01 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6CGZ1Mc007179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 16:35:01 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 11:35:01 -0500
From: "Bernie Volz (volz)" 
To: "sarikaya@ieee.org" 
Thread-Topic: [dhcwg] Slides for Berlin DHC WG presentations! (And last chance to request time!!)
Thread-Index: Ac5+US1wtpjb+glbSfSRNvO3R471iwARmkKAACEAMcA=
Date: Fri, 12 Jul 2013 16:35:00 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185E0AA0@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E185DDCCF@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.255.139]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185E0AA0xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Slides for Berlin DHC WG presentations! (And last chance to request time!!)
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, 12 Jul 2013 16:35:07 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185E0AA0xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:

I will add the item to the agenda, but as this is a late request, not a DHC=
 WG work item, and hasn't really had discussion on this list, it will be at=
 the end and there is a [good] chance that we may not get to it. (The chair=
s also reserve the right to add other items before this, should we get addi=
tional requests.)

But even if there is no time, having the slides available will provide some=
 value.

You should also see what you can do to stimulate discussion on the mailing =
list. And, to that end I'll provide a few additional comments (these are mo=
stly with WG co-chair hat off).

The introduction also mentions GRE and you might want to look at http://www=
.ietf.org/internet-drafts/draft-xue-dhc-dynamic-gre-00.txt. Though it does =
not look like there is any direct overlap (at least from my very cursory lo=
ok at your and that draft).

The document also appears to be a bit incomplete (for example, section 8 on=
ly mentions the DHCPv4 messages - nothing about DHCPv6).

Section 7 also concerns me as it seems to imply fairly specialized processi=
ng on the DHCPv6 server, if not outright management (and hence additional s=
tate) of the multicast addresses. But that may just expose my lack of knowl=
edge of this particular problem space - which also brings up whether there =
are other IETF WGs that would be involved in this work.


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B=
ehcet Sarikaya
Sent: Thursday, July 11, 2013 3:35 PM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Slides for Berlin DHC WG presentations! (And last chan=
ce to request time!!)

Hi Bernie,

A short slot for

http://tools.ietf.org/id/draft-sarikaya-dhc-vxlan-multicast-00.txt

please.

Regards,

Behcet
On Thu, Jul 11, 2013 at 11:10 AM, Bernie Volz (volz) > wrote:
Please do provide your slides if you're on the agenda (or requested time). =
Email them to the dhc-chairs@tools.ietf.org and one of us will post them.

I'll update the agenda tomorrow (assuming Tomek and I can find a time to re=
view and attempt to finalize the agenda).

If you haven't submitted a request for time, please do so ASAP. We may not =
be able to accommodate.


-          Tomek & Bernie

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


--_000_489D13FBFA9B3E41812EA89F188F018E185E0AA0xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi:


 <=
/p>

I will add the item to th=
e agenda, but as this is a late request, not a DHC WG work item, and hasn&#=
8217;t really had discussion on this list, it will be at the end
 and there is a [good] chance that we may not get to it. (The chairs also r=
eserve the right to add other items before this, should we get additional r=
equests.)


 <=
/p>

But even if there is no t=
ime, having the slides available will provide some value.=



 <=
/p>

You should also see what =
you can do to stimulate discussion on the mailing list. And, to that end I&=
#8217;ll provide a few additional comments (these are mostly with
 WG co-chair hat off).


 <=
/p>

The introduction also men=
tions GRE and you might want to look at
http://www.ietf.org/internet-drafts/draft-xue-dhc-dynamic-gre-00.txt<=
/a>. Though it does not look like there is any direct overlap (at least fro=
m my very cursory look at your and
 that draft).


 <=
/p>

The document also appears=
 to be a bit incomplete (for example, section 8 only mentions the DHCPv4 me=
ssages – nothing about DHCPv6).


 <=
/p>

Section 7 also concerns m=
e as it seems to imply fairly specialized processing on the DHCPv6 server, =
if not outright management (and hence additional state)
 of the multicast addresses. But that may just expose my lack of knowledge =
of this particular problem space – which also brings up whether there=
 are other IETF WGs that would be involved in this work.<=
/p>

 <=
/p>

- =
        
Bernie=



 <=
/p>

From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Behcet Sarikaya

Sent: Thursday, July 11, 2013 3:35 PM

To: Bernie Volz (volz)

Cc: dhcwg@ietf.org

Subject: Re: [dhcwg] Slides for Berlin DHC WG presentations! (And la=
st chance to request time!!)


 


Hi Bernie,



A short slot for



http://tools.ietf.org/id/draft-sarikaya-dhc-vxlan-multicast-00.txt<=
br>


please.



Regards,



Behcet




On Thu, Jul 11, 2013 at 11:10 AM, Bernie Volz (volz)=
 <volz@cisco.com=
> wrote:






Please do provide your slides if you’re on the agenda (or re=
quested time). Email them to the
dhc-chairs@t=
ools.ietf.org and one of us will post them.


 


I’ll update the agenda tomorrow (assuming Tomek and I can fi=
nd a time to review and attempt to finalize the agenda).


 


If you haven’t submitted a request for time, please do so AS=
AP. We may not be able to accommodate.


 


-      &nb=
sp;   Tomek & Bernie








_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/dhcwg




 






--_000_489D13FBFA9B3E41812EA89F188F018E185E0AA0xmbrcdx04ciscoc_--

From sarikaya2012@gmail.com  Fri Jul 12 12:44: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 0833F21F9F3C for ; Fri, 12 Jul 2013 12:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74J8G8Shej3Y for ; Fri, 12 Jul 2013 12:44:41 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4DB21F9EE9 for ; Fri, 12 Jul 2013 12:44:40 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id fs12so8077805lab.12 for ; Fri, 12 Jul 2013 12:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DIYKUQzNzRC6SaViG3Kshf+I7fxIjOMrIktYG64rJmI=; b=ub6IrXV3rbjO2K3O5aYT4Fburo6BujPTpr1XhGH3cI/cgjcgro6K74R6ztRcMlUy8q 6xpxe84aZH0CpMfIdrXdmMvkXRmGDF74kgJpf5uCdHbKkXT9uvUWiabbuBz8oeWE+ows +Vr4gIR4gnQxOXnBirPdu8ApHO+o78aib0Nu01rEandX1sjTe7EMS9XOciYmCkKSETuR EGlDleEsesYhOn2VzfdlMgWyyr1SLKMtbbY0wFc0YBhouQtLkf4nSrGuufvlIsw/EdMx 7nKYTWuevslddSAGbHHxkXtwIQ1rIMV9lmvrTNTYONN3M6Qby3yXsbDNZdgtlVnm/tQM iW3w==
MIME-Version: 1.0
X-Received: by 10.152.88.105 with SMTP id bf9mr19971601lab.38.1373658279314; Fri, 12 Jul 2013 12:44:39 -0700 (PDT)
Received: by 10.114.176.37 with HTTP; Fri, 12 Jul 2013 12:44:39 -0700 (PDT)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185E0AA0@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E185DDCCF@xmb-rcd-x04.cisco.com>  <489D13FBFA9B3E41812EA89F188F018E185E0AA0@xmb-rcd-x04.cisco.com>
Date: Fri, 12 Jul 2013 14:44:39 -0500
Message-ID: 
From: Behcet Sarikaya 
To: "Bernie Volz (volz)" 
Content-Type: multipart/alternative; boundary=001a11c36722c80bb404e155bdd2
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Slides for Berlin DHC WG presentations! (And last chance to request time!!)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jul 2013 19:44:42 -0000

--001a11c36722c80bb404e155bdd2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Bernie,

Please see inline.

Regards,

Behcet

On Fri, Jul 12, 2013 at 11:35 AM, Bernie Volz (volz)  wrote=
:

>  Hi:****
>
> ** **
>
> I will add the item to the agenda, but as this is a late request, not a
> DHC WG work item, and hasn=92t really had discussion on this list, it wil=
l be
> at the end and there is a [good] chance that we may not get to it. (The
> chairs also reserve the right to add other items before this, should we g=
et
> additional requests.)****
>
> ** **
>
> But even if there is no time, having the slides available will provide
> some value.****
>
> ** **
>
> You should also see what you can do to stimulate discussion on the mailin=
g
> list. And, to that end I=92ll provide a few additional comments (these ar=
e
> mostly with WG co-chair hat off).****
>
> **
>

Yes, dhc folks, please read my draft and comment on it.


> **
>
> The introduction also mentions GRE and you might want to look at
> http://www.ietf.org/internet-drafts/draft-xue-dhc-dynamic-gre-00.txt.
> Though it does not look like there is any direct overlap (at least from m=
y
> very cursory look at your and that draft).****
>
> **
>

You are right there is no overlap. Basically, there are two encapsulation
techniques, one is UDP based in VXLAN and the other is GRE based in nvgre,
resulting in the same type of network. Multicast operation which is the
subject of my draft is common in both nvgre and VXLAN.
While draft-xue-dhc-dynamic-gre addresses establishment of the GRE tunnel.


> **
>
> The document also appears to be a bit incomplete (for example, section 8
> only mentions the DHCPv4 messages =96 nothing about DHCPv6).****
>
> **
>

I think Section 8 does not contribute anything so I removed it. Sorry for
the confusion.


> **
>
> Section 7 also concerns me as it seems to imply fairly specialized
> processing on the DHCPv6 server, if not outright management (and hence
> additional state) of the multicast addresses. But that may just expose my
> lack of knowledge of this particular problem space =96 which also brings =
up
> whether there are other IETF WGs that would be involved in this work.****
>
> **
>

Thanks for your concern. In fact the server operation is completely
stateless, the information Server needs is provided by the Client in DHCP
Request or Solicit messages, I clarified it by adding VTEP as DHCP Client
to the text.
I am going to post rev 01 on Monday, just in case there are other comments.


> **
>
> **-          **Bernie****
>
> ** **
>
> *From:* dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] *On Behalf
> Of *Behcet Sarikaya
> *Sent:* Thursday, July 11, 2013 3:35 PM
> *To:* Bernie Volz (volz)
> *Cc:* dhcwg@ietf.org
> *Subject:* Re: [dhcwg] Slides for Berlin DHC WG presentations! (And last
> chance to request time!!)****
>
> ** **
>
> Hi Bernie,
>
> A short slot for
>
> http://tools.ietf.org/id/draft-sarikaya-dhc-vxlan-multicast-00.txt
>
> please.
>
> Regards,
>
> Behcet****
>
> On Thu, Jul 11, 2013 at 11:10 AM, Bernie Volz (volz) 
> wrote:****
>
> Please do provide your slides if you=92re on the agenda (or requested tim=
e).
> Email them to the dhc-chairs@tools.ietf.org and one of us will post them.=
*
> ***
>
>  ****
>
> I=92ll update the agenda tomorrow (assuming Tomek and I can find a time t=
o
> review and attempt to finalize the agenda).****
>
>  ****
>
> If you haven=92t submitted a request for time, please do so ASAP. We may =
not
> be able to accommodate.****
>
>  ****
>
> -          Tomek & Bernie****
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg****
>
> ** **
>

--001a11c36722c80bb404e155bdd2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Bernie,

Please see inline.

Regards,

Behcet

<=
div class=3D"gmail_quote">On Fri, Jul 12, 2013 at 11:35 AM, Bernie Volz (vo=
lz) <volz@cisco.com> wrote:













Hi:<=
/p>

=A0<=
/p>

I will add the item to th=
e agenda, but as this is a late request, not a DHC WG work item, and hasn=
=92t really had discussion on this list, it will be at the end
 and there is a [good] chance that we may not get to it. (The chairs also r=
eserve the right to add other items before this, should we get additional r=
equests.)


=A0<=
/p>

But even if there is no t=
ime, having the slides available will provide some value.



=A0<=
/p>

You should also see what =
you can do to stimulate discussion on the mailing list. And, to that end I=
=92ll provide a few additional comments (these are mostly with
 WG co-chair hat off).


=A0

Yes, dhc folks, please read my draft and comm=
ent on it.

=A0
=




The introduction also men=
tions GRE and you might want to look at
http://www.ietf.org/internet-drafts/draft-xue-dhc-d=
ynamic-gre-00.txt. Though it does not look like there is any direct ove=
rlap (at least from my very cursory look at your and
 that draft).


=A0

You are right there is no overlap. Basically,=
 there are two encapsulation techniques, one is UDP based in VXLAN and the =
other is GRE based in nvgre, resulting in the same type of network. Multica=
st operation which is the subject of my draft is common in both nvgre and V=
XLAN.

While draft-xue-dhc-dynamic-gre addresses establishment of the GRE tunnel.<=
br>=A0




The document also appears=
 to be a bit incomplete (for example, section 8 only mentions the DHCPv4 me=
ssages =96 nothing about DHCPv6).



=A0

I think Section 8 does not contribute anythin=
g so I removed it. Sorry for the confusion.

=A0
=




Section 7 also concerns m=
e as it seems to imply fairly specialized processing on the DHCPv6 server, =
if not outright management (and hence additional state)
 of the multicast addresses. But that may just expose my lack of knowledge =
of this particular problem space =96 which also brings up whether there are=
 other IETF WGs that would be involved in this work.


=A0

Thanks for your concern. In fact the server o=
peration is completely stateless, the information Server needs is provided =
by the Client in DHCP Request or Solicit messages, I clarified it by adding=
 VTEP as DHCP Client to the text.

I am going to post rev 01 on Monday, just in case there are other comments.=

=A0




-=A0=A0=A0=A0=A0=A0=A0=A0=A0
Bernie=



=A0<=
/p>

From: dhcwg-bounces@ietf.org=
 [mailto:dh=
cwg-bounces@ietf.org]
On Behalf Of Behcet Sarikaya

Sent: Thursday, July 11, 2013 3:35 PM

To: Bernie Volz (volz)

Cc: dhcwg@ietf.o=
rg

Subject: Re: [dhcwg] Slides for Berlin DHC WG presentations! (And la=
st chance to request time!!)


=A0


Hi Bernie,



A short slot for



http://tools.ietf.org/id/draft-sarikaya-dhc-vxlan-mul=
ticast-00.txt



please.



Regards,



Behcet




On Thu, Jul 11, 2013 at 11:10 AM, Bernie Volz (volz)=
 <volz@cisco.com=
> wrote:






Please do provide your slides if you=92re on the age=
nda (or requested time). Email them to the
dhc-chairs@t=
ools.ietf.org and one of us will post them.


=A0


I=92ll update the agenda tomorrow (assuming Tomek an=
d I can find a time to review and attempt to finalize the agenda).


=A0


If you haven=92t submitted a request for time, pleas=
e do so ASAP. We may not be able to accommodate.


=A0


-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tome=
k & Bernie








_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/dhcwg




=A0










--001a11c36722c80bb404e155bdd2--

From rdroms.ietf@gmail.com  Sat Jul 13 13:57: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 C320E21F9E3D for ; Sat, 13 Jul 2013 13:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.585
X-Spam-Level: 
X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi8TnGF2Nssu for ; Sat, 13 Jul 2013 13:57:38 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3130F21F8EC3 for ; Sat, 13 Jul 2013 13:57:38 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id hu16so953028qab.15 for ; Sat, 13 Jul 2013 13:57:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4Y2TIKyO4WygZl2+HMBDPizd5074pn0yEEh3HPhQbN0=; b=huE9w+sYJgxs7GKBWMfOSObGncBbj1gSJNQTQZSwGriiVnLeeofSPN/on2zqZJPdii /waXPQaY7lNU8OcTpw9Ic38pk4Qr8loF/tJEUYtj5bnuOOdmOmlHTxp/sCJ9nYUrRtZO ntvJhBKE+a/PI6zQuO6eg6oR0nk6OA6GMLMROk6KRhO2PAhfLiEpSGtk9jU9MuiVByO+ 2x+tlUYCTfFf4NB+MdtJIJV0zqqDTG5hQfzVQHXmcDWAFtlKKzzr1cxj0jtTGp/yz+Pg xA+QtDSR8oyHp71+2+oQ/f55YIZe3cGcOkC7XjJXrHIfyvcUrc9diOrTkHm7D/n2OUIV za3A==
X-Received: by 10.49.86.69 with SMTP id n5mr35553326qez.69.1373749057626; Sat, 13 Jul 2013 13:57:37 -0700 (PDT)
Received: from [10.86.252.25] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id ng3sm43233139qeb.0.2013.07.13.13.57.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 13:57:36 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <51E0300A.4000303@gmail.com>
Date: Sat, 13 Jul 2013 16:57:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <04BDE310-8E45-466F-B2A0-38A0B78F8ECF@gmail.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>  <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com> <51E0300A.4000303@gmail.com>
To: Tomek Mrugalski , "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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: Sat, 13 Jul 2013 20:57:40 -0000

On Jul 12, 2013, at 12:34 PM 7/12/13, Tomek Mrugalski =
 wrote:

> On 12.07.2013 17:48, Bernie Volz (volz) wrote:
>> I think if there was text to limit the SOLMAX (and INF) option value
>> to be 120 seconds to 1 day (24 hours), we could leave the options in
>> place (and let the client use the values from Advertise messages).
>> That would avoid really bad values and still give the possibility to
>> set the value back to 120 for those cases where valid service is
>> expected.
> I like this. With those lower and upper bounds, the solution #2 (have =
it
> in advertise as the text specifies now) would be ok.
>=20
>> I'm not sure removing the options is the best avenue - as it provides
>> no way to 'correct' any problems that might occur if the 3600 seconds
>> turns out to have negative operational consequences.
> Good point.

Unless I hear otherwise, I'll modify the solmaxrt draft to:

1) allow the SOL_MAX_RT option to appear in any message
2) limit the valid range of values to 120 seconds to 1 day

and publish a new rev before the deadline Monday.

- Ralph

>=20
> Tomek


From tomasz.mrugalski@gmail.com  Sat Jul 13 14:16: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 B68EB21F9AAE for ; Sat, 13 Jul 2013 14:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level: 
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ5oA8G87amp for ; Sat, 13 Jul 2013 14:16:40 -0700 (PDT)
Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 123C621F9A17 for ; Sat, 13 Jul 2013 14:16:39 -0700 (PDT)
Received: by mail-bk0-f45.google.com with SMTP id je9so4155710bkc.18 for ; Sat, 13 Jul 2013 14:16:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=MK6B7X68s6BpAu/ipyTDtMy6MeJfhLokNGrmc+Q7K/w=; b=w0SGrUa/JlWi/8Jl/3hoyj4R/hq1Hk6khrxvo268joC9WTTHdkjc1cKlS4J+QPZW/p cMN4Waf+E+S8xnWL61oUk+eHHMEdvm3c13W0DXSGSba5XPdhBVdL5AIcLWbe/pnYaIWj U9L/4rpvzpjdxybu7yIP7r96bF2q+KdTOnEw7r3ZsWQ4EncmSj1DzRATiJP1xN0/x7/w Hw8EB1eKq3LPY5MwZVv9L8/xdQIniqz0OZWxRh4DcOTNamXptTcOWKADiZIHt6U4fl7H izM4vWISEz38lT/ztlklvrcBgJAuAT64ZNt5K2bZySnbfbnfZnKNWeVYb9hs7Xwi08tC UWzQ==
X-Received: by 10.205.22.73 with SMTP id qv9mr7106741bkb.8.1373750197748; Sat, 13 Jul 2013 14:16:37 -0700 (PDT)
Received: from thomson-osx.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id eu16sm10390961bkc.0.2013.07.13.14.16.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 14:16:36 -0700 (PDT)
Message-ID: <51E1C3B2.10300@gmail.com>
Date: Sat, 13 Jul 2013 23:16:34 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ralph Droms 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>  <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com> <51E0300A.4000303@gmail.com> <04BDE310-8E45-466F-B2A0-38A0B78F8ECF@gmail.com>
In-Reply-To: <04BDE310-8E45-466F-B2A0-38A0B78F8ECF@gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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: Sat, 13 Jul 2013 21:16:40 -0000

On 13-07-13 22:57, Ralph Droms wrote:
> Unless I hear otherwise, I'll modify the solmaxrt draft to:
> 
> 1) allow the SOL_MAX_RT option to appear in any message
> 2) limit the valid range of values to 120 seconds to 1 day
That's a good way forward. It addresses all my concerns. Thank you.

Tomek



From volz@cisco.com  Sat Jul 13 16:57:04 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 A6AEB21F99C2 for ; Sat, 13 Jul 2013 16:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.572
X-Spam-Level: 
X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW27TcqKUL4l for ; Sat, 13 Jul 2013 16:56:59 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D836A21F967F for ; Sat, 13 Jul 2013 16:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=601; q=dns/txt; s=iport; t=1373759820; x=1374969420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IxUCwQIn6Axi2W2OR1/JCrDHLEceJQsZtUY5BZN01jQ=; b=CttZUvXl1FL3Jn5BO8b9L5mHpeu1GGbxJUmpXqOlNuZ0FYXNDezZCCAq v35JtgRq4NoXx7eRnWgC1kIdv45e4dmXYuEx6ij8zgpNV9j/5i6GqsEUb 19buLot7GYcg8kohQxS3p4bY2uH9dla9HZGVpbwOL0o22MvIQBXnnaIQV U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FACzo4VGtJXHA/2dsb2JhbABZgwY0gw6/IIEKFnSCIwEBAQMBAQEBNzQLBQsCAQgOCh4QIQYLJQIEDgWHfgMJBgysZQ2IWgSMeoEzgQQzB4MLbQOVc4FpjCeFJoFZgTmBaQ
X-IronPort-AV: E=Sophos;i="4.89,661,1367971200"; d="scan'208";a="234495751"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 13 Jul 2013 23:56:59 +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 r6DNuxb8019332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Jul 2013 23:56:59 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Sat, 13 Jul 2013 18:56:58 -0500
From: "Bernie Volz (volz)" 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOgA5IcZKJuEL5DUG5VDaR1cfcIpljSTXB
Date: Sat, 13 Jul 2013 23:56:58 +0000
Message-ID: <4094E80F-D17D-452C-9107-6530D36B6DB1@cisco.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>  <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com> <51E0300A.4000303@gmail.com> <04BDE310-8E45-466F-B2A0-38A0B78F8ECF@gmail.com>, <51E1C3B2.10300@gmail.com>
In-Reply-To: <51E1C3B2.10300@gmail.com>
Accept-Language: en-US
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
Cc: "dhcwg@ietf.org WG" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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: Sat, 13 Jul 2013 23:57:04 -0000

Yes, I agree.

- Bernie (from iPad)

On Jul 13, 2013, at 5:16 PM, "Tomek Mrugalski" =
 wrote:

> On 13-07-13 22:57, Ralph Droms wrote:
>> Unless I hear otherwise, I'll modify the solmaxrt draft to:
>>=20
>> 1) allow the SOL_MAX_RT option to appear in any message
>> 2) limit the valid range of values to 120 seconds to 1 day
> That's a good way forward. It addresses all my concerns. Thank you.
>=20
> Tomek
>=20
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

From Ted.Lemon@nominum.com  Sun Jul 14 08:51: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 F1FB321F9A05 for ; Sun, 14 Jul 2013 08:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level: 
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6X0KQF7Z1cD for ; Sun, 14 Jul 2013 08:51:05 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 05CBC21F9339 for ; Sun, 14 Jul 2013 08:51:05 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUeLI6Fdx4UE+BYgM0eFGmsKApzww/3bc@postini.com; Sun, 14 Jul 2013 08:51:05 PDT
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 BCAE91B823A for ; Sun, 14 Jul 2013 08:51:04 -0700 (PDT)
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 B5DBB190052; Sun, 14 Jul 2013 08:51:04 -0700 (PDT) (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; Sun, 14 Jul 2013 08:51:04 -0700
From: Ted Lemon 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfu9VUP53RJRLU0mAdQBCnOBdOZlky14A
Date: Sun, 14 Jul 2013 15:51:03 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520F98F@mbx-01.win.nominum.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com> <51DFE245.6080909@gmail.com>
In-Reply-To: <51DFE245.6080909@gmail.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: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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: Sun, 14 Jul 2013 15:51:12 -0000

On Jul 12, 2013, at 7:02 AM, Tomek Mrugalski  w=
rote:
> I would have named those
> registries differently, but I suppose there's no procedure (or a real
> need) to rename them. I think the text in IANA considerations is a bit
> minimalistic, but correct.

If there is strong desire in the working group to change the name, we can d=
o that.   It would require a draft that updates all the specs that use that=
 name, including the BOOTP specs.   It might be worth doing; if you think i=
t is, feel free to make it happen.


From Ted.Lemon@nominum.com  Sun Jul 14 16:04:30 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 F3F1221F9C39 for ; Sun, 14 Jul 2013 16:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.6
X-Spam-Level: 
X-Spam-Status: No, score=-106.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgQVCpV-C9J4 for ; Sun, 14 Jul 2013 16:04:23 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14421F9A92 for ; Sun, 14 Jul 2013 16:04:23 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUeMudo9sixkaEn+JH76FQ0lNR2wzz2JQ@postini.com; Sun, 14 Jul 2013 16:04:23 PDT
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 7D1D91B821E for ; Sun, 14 Jul 2013 16:04:22 -0700 (PDT)
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 232D1190052 for ; Sun, 14 Jul 2013 16:04:20 -0700 (PDT) (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; Sun, 14 Jul 2013 16:04:20 -0700
From: Ted Lemon 
To: "dhcwg@ietf.org WG" 
Thread-Topic: Questions about PD and PD_EXCLUDE
Thread-Index: AQHOgOZ4tJh/uNsHOEGgjsiYWtCCVQ==
Date: Sun, 14 Jul 2013 23:04:18 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630775210444@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: <587D50ACC47E1245A7A99D8A0318CC77@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dhcwg] Questions about PD and PD_EXCLUDE
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: Sun, 14 Jul 2013 23:04:30 -0000

This question was asked during a conversation I was having with a developer=
 a while back, and I don't know the answer, so I'm curious to know what wor=
king group participants think.

Suppose a client asks for a /48 and gets a /64.   Can the client do a secon=
d request and ask for additional prefixes, in hopes of getting enough to sa=
tisfy its needs, even if they aren't contiguous?   What do current implemen=
tations do if they get a DHCP Discover with two IA_PDs in it?   What do the=
y do if they get a DHCP Discover with an IA_PD in it with a different IAID,=
 when the DUID already has a prefix assigned to it, on a different IAID?

I think that what should happen is that if local policy allows it, the seco=
nd IA_PD should get an allocation, in either case.   I think that it's unli=
kely that existing clients would follow this behavior, but I think it's mea=
ningful behavior.

I suspect that existing relay agents that snoop on DHCP PD messages to set =
up routing may currently do the wrong thing if more than one IA_PD appears =
in the message.

Thoughts?


From Ted.Lemon@nominum.com  Sun Jul 14 16:16:37 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 0848821F99A9 for ; Sun, 14 Jul 2013 16:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.6
X-Spam-Level: 
X-Spam-Status: No, score=-106.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvQHldRYRaQn for ; Sun, 14 Jul 2013 16:16:30 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 53D8521F86D5 for ; Sun, 14 Jul 2013 16:16:30 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUeMxTZ1cEu0ikuB+Xa4VTqMs1mMEKg1d@postini.com; Sun, 14 Jul 2013 16:16:30 PDT
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 BB0F51B821E for ; Sun, 14 Jul 2013 16:16:29 -0700 (PDT)
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 B5531190052 for ; Sun, 14 Jul 2013 16:16:29 -0700 (PDT) (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; Sun, 14 Jul 2013 16:16:24 -0700
From: Ted Lemon 
To: "dhcwg@ietf.org WG" 
Thread-Topic: [dhcwg] Questions about PD and PD_EXCLUDE
Thread-Index: AQHOgOZ4tJh/uNsHOEGgjsiYWtCCVZllQ9uA
Date: Sun, 14 Jul 2013 23:16:23 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752104EF@mbx-01.win.nominum.com>
References: <8D23D4052ABE7A4490E77B1A012B630775210444@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775210444@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] Questions about PD and PD_EXCLUDE
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: Sun, 14 Jul 2013 23:16:37 -0000

On Jul 14, 2013, at 4:04 PM, Ted Lemon  wrote:
> What do current implementations do if they get a DHCP Discover with two I=
A_PDs in it?

DHCP Solicit.   Sigh.


From akostur@incognito.com  Sun Jul 14 16:54:07 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 AD61421F9B9F for ; Sun, 14 Jul 2013 16:54:07 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0rsJxXSnPrE for ; Sun, 14 Jul 2013 16:54:03 -0700 (PDT)
Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 27D8C21F9B85 for ; Sun, 14 Jul 2013 16:53:58 -0700 (PDT)
Received: from mail-vb0-f50.google.com ([209.85.212.50]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUeM6Fd/2JvqHhnBFB4iLz8zbgoEKOO7d@postini.com; Sun, 14 Jul 2013 16:53:59 PDT
Received: by mail-vb0-f50.google.com with SMTP id w16so2744648vbb.37 for ; Sun, 14 Jul 2013 16:53:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ziusdO9KLfAX2/oFyo3v2kc9oAIHfjGXNia625G6N28=; b=N9QwdBxiRDAQRVHB8aLICLZONbNvdCxlm3d3GauHe2/GfVtT8wnbzOJIzcY/42DiH6 vv6JF2kkM/913BjEatsSPERPOh+leVXZoTHnSPAvIBCc2TN9SiXaQgJXIeFSRokz+ghV bapeG1B9LitnjVj48RpnteMkN2T1/5QeqMntr7u6DjXVs4GQyuE1EbgT1hiaXh5DL1Bx GYBf/+MHQ2Zx5pe/wrmDuG/vhXXXI8SxfGxEseUTb5Nwwv4tKggSUjQJH5oyZDyxL+Cx D8KQA19jeck7oLhekPqxJrRt81Ddp80TXqYld3IV6dGWOgFiU5FwL9L7eQ84ElwMptHn q5ag==
X-Received: by 10.52.117.77 with SMTP id kc13mr23333273vdb.67.1373846036721; Sun, 14 Jul 2013 16:53:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.117.77 with SMTP id kc13mr23333272vdb.67.1373846036594; Sun, 14 Jul 2013 16:53:56 -0700 (PDT)
Received: by 10.220.184.132 with HTTP; Sun, 14 Jul 2013 16:53:56 -0700 (PDT)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775210444@mbx-01.win.nominum.com>
References: <8D23D4052ABE7A4490E77B1A012B630775210444@mbx-01.win.nominum.com>
Date: Sun, 14 Jul 2013 16:53:56 -0700
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: ALoCoQlmb9tv9KzqyZsv8MYI3RUnbSHKPtC4sw9aQmOzqsJcpAGZtGVZo8lA5j9alV6rG4AFGkauVlr1hOdqM9xCB7aqR9/p2sHWJWJbMETx3d8OciF9NJL/BbMIZQuEZ06ud6rFVF5mhpToFgf9Zfk9aY2a4OujBg==
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] Questions about PD and PD_EXCLUDE
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: Sun, 14 Jul 2013 23:54:07 -0000

> What do current implementations do if they get a DHCP Discover with two I=
A_PDs in it?

For our implementation, the client would get two prefixes assigned to
it, one per IA.  Assuming the service isn't otherwise configured to
prevent the second allocation.  (Of course, reading Solicit for
Discover)

A client might be asking for two different prefixes as it may have two
different networks that it wants a prefix for.  It could ask for a /63
and split it by hand, or it could ask for two separate /64s.

On Sun, Jul 14, 2013 at 4:04 PM, Ted Lemon  wrote:
> This question was asked during a conversation I was having with a develop=
er a while back, and I don't know the answer, so I'm curious to know what w=
orking group participants think.
>
> Suppose a client asks for a /48 and gets a /64.   Can the client do a sec=
ond request and ask for additional prefixes, in hopes of getting enough to =
satisfy its needs, even if they aren't contiguous?   What do current implem=
entations do if they get a DHCP Discover with two IA_PDs in it?   What do t=
hey do if they get a DHCP Discover with an IA_PD in it with a different IAI=
D, when the DUID already has a prefix assigned to it, on a different IAID?
>
> I think that what should happen is that if local policy allows it, the se=
cond IA_PD should get an allocation, in either case.   I think that it's un=
likely that existing clients would follow this behavior, but I think it's m=
eaningful behavior.
>
> I suspect that existing relay agents that snoop on DHCP PD messages to se=
t up routing may currently do the wrong thing if more than one IA_PD appear=
s in the message.
>
> Thoughts?
>
> _______________________________________________
> 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 volz@cisco.com  Sun Jul 14 17:47:26 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 8AC0621F9ABD for ; Sun, 14 Jul 2013 17:47:26 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN1QHDV5Zew4 for ; Sun, 14 Jul 2013 17:47:21 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B644F21F9AA3 for ; Sun, 14 Jul 2013 17:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2573; q=dns/txt; s=iport; t=1373849241; x=1375058841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c28Ecfy5QXWvwmRhqnAKmOYW9YXkT3SsYnKFRbR9gj0=; b=X8REIlOZlJzqzZdUD+aheEieOB7LLX77cP5W3ykfpKBnOLjbVVo8izzN k0iNMpM8iHmwp8hP0GzhI1arrIdEVhvgr/lBiw13Yd7EKZVcWMXJP4Hk0 QvSaUfjexwEPj9QpaFtplq3Qo77zdnUbOcjVlgYOC8mKM2lCLAE8xbWCk A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAG9F41GtJXG9/2dsb2JhbABXA4MGNMIegQwWdIIjAQEBAQIBAQEBNzQLEAIBCA4KFAoQJwskAQIBAw4FiAoGDLU1BI49dAgbEAcRgnptA5dciiKHK4JCUA
X-IronPort-AV: E=Sophos;i="4.89,665,1367971200"; d="scan'208";a="234750319"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 00:47:21 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6F0lK9m000626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 00:47:20 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 19:47:20 -0500
From: "Bernie Volz (volz)" 
To: Andre Kostur 
Thread-Topic: [dhcwg] Questions about PD and PD_EXCLUDE
Thread-Index: AQHOgOZ4tJh/uNsHOEGgjsiYWtCCVZllLNIA//+7CdQ=
Date: Mon, 15 Jul 2013 00:47:06 +0000
Message-ID: <18F972E6-48A9-47A7-959E-6F88E3A13E48@cisco.com>
References: <8D23D4052ABE7A4490E77B1A012B630775210444@mbx-01.win.nominum.com>, 
In-Reply-To: 
Accept-Language: en-US
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
Cc: "dhcwg@ietf.org WG" , Ted Lemon 
Subject: Re: [dhcwg] Questions about PD and PD_EXCLUDE
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, 15 Jul 2013 00:47:26 -0000

Yes, Cisco Prime Network Registrar would also provide the two prefixes (one=
 per IA).

It really is up to the client.

I think CMTS (relay agents) now support multiple PDs per client.=20

- Bernie (from iPad)

On Jul 14, 2013, at 7:54 PM, "Andre Kostur"  wrote:

>> What do current implementations do if they get a DHCP Discover with two =
IA_PDs in it?
>=20
> For our implementation, the client would get two prefixes assigned to
> it, one per IA.  Assuming the service isn't otherwise configured to
> prevent the second allocation.  (Of course, reading Solicit for
> Discover)
>=20
> A client might be asking for two different prefixes as it may have two
> different networks that it wants a prefix for.  It could ask for a /63
> and split it by hand, or it could ask for two separate /64s.
>=20
> On Sun, Jul 14, 2013 at 4:04 PM, Ted Lemon  wrote:
>> This question was asked during a conversation I was having with a develo=
per a while back, and I don't know the answer, so I'm curious to know what =
working group participants think.
>>=20
>> Suppose a client asks for a /48 and gets a /64.   Can the client do a se=
cond request and ask for additional prefixes, in hopes of getting enough to=
 satisfy its needs, even if they aren't contiguous?   What do current imple=
mentations do if they get a DHCP Discover with two IA_PDs in it?   What do =
they do if they get a DHCP Discover with an IA_PD in it with a different IA=
ID, when the DUID already has a prefix assigned to it, on a different IAID?
>>=20
>> I think that what should happen is that if local policy allows it, the s=
econd IA_PD should get an allocation, in either case.   I think that it's u=
nlikely that existing clients would follow this behavior, but I think it's =
meaningful behavior.
>>=20
>> I suspect that existing relay agents that snoop on DHCP PD messages to s=
et up routing may currently do the wrong thing if more than one IA_PD appea=
rs in the message.
>>=20
>> Thoughts?
>>=20
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>=20
>=20
>=20
> --=20
> Andre Kostur
> Distinguished Software Architect & Engineer
> P: 604-678-2864
> E: akostur@incognito.com
> Toll-Free: 1-800-877-1856
>=20
>=20
> F: 604-678-2864
> VoIP: sip:864@sip.incognito.com
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

From ghalwasi@cisco.com  Sun Jul 14 19:37: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 1E44321F9B19 for ; Sun, 14 Jul 2013 19:37:15 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIflUxxcLiRg for ; Sun, 14 Jul 2013 19:37:09 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7A21F92A5 for ; Sun, 14 Jul 2013 19:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=322; q=dns/txt; s=iport; t=1373855829; x=1375065429; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2JM571ditK2zcU4RonU5bhT9f3z2fSK80JYwVWFBBz8=; b=RKPAESfj5AOIDTIgkMbpJH0BN1DkHlFJ8LzUy0WlITbiKSuZShNw18sz kK/XnEEx51PpcALJZXdNTsdsYG6hSiSdK4nP3fs/8NMprBFXdlP8x0+aC EOZid0G4ZVs7yUui/9Wr12865fq+36TYUCNARsVUKsx+KYbg+XDwDdWjR I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAPte41GtJV2Y/2dsb2JhbABagwaBA8FPgQwWdIIkAQEBAzpPAgEIIhQQMiUCBAEaiAi1Q48zOIMLbQOhfocrgxKCKA
X-IronPort-AV: E=Sophos;i="4.89,666,1367971200"; d="scan'208";a="234750573"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 15 Jul 2013 02:37:09 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6F2b8lT003021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 02:37:08 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.78]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 21:37:08 -0500
From: "Gaurav Halwasia (ghalwasi)" 
To: Ted Lemon , "dhcwg@ietf.org WG" 
Thread-Topic: Questions about PD and PD_EXCLUDE
Thread-Index: AQHOgOZ4tJh/uNsHOEGgjsiYWtCCVZllBfnQ
Date: Mon, 15 Jul 2013 02:37:08 +0000
Message-ID: <90903C21C73202418A48BFBE80AEE5EB230147E7@xmb-aln-x06.cisco.com>
References: <8D23D4052ABE7A4490E77B1A012B630775210444@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775210444@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.57]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dhcwg] Questions about PD and PD_EXCLUDE
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, 15 Jul 2013 02:37:15 -0000

>I suspect that existing relay agents that snoop on DHCP PD messages to set=
 up routing may currently do the wrong thing if more than one IA_PD appears=
 in the message.

Implementations which I work on and aware of shall add the route for both t=
he IA_PD's. What do you mean by "wrong thing" exactly.?

-Gaurav

From internet-drafts@ietf.org  Mon Jul 15 01:14: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 659AE21F9E84; Mon, 15 Jul 2013 01:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtevXKE4aGlk; Mon, 15 Jul 2013 01:14:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC4521F9E39; Mon, 15 Jul 2013 01:13:51 -0700 (PDT)
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.51.p2
Message-ID: <20130715081351.12597.80962.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 01:13:51 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-02.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, 15 Jul 2013 08:14:24 -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           : Modification to Default Values of SOL_MAX_RT and INF_MAX=
_RT
	Author(s)       : Ralph Droms
	Filename        : draft-ietf-dhc-dhcpv6-solmaxrt-update-02.txt
	Pages           : 7
	Date            : 2013-07-15

Abstract:
   This document updates RFC 3315 by redefining the default values for
   SOL_MAX_RT and INF_MAX_RT, and defining options through which a
   DHCPv6 server can override the client's default value for SOL_MAX_RT
   and INF_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-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-solmaxrt-update-02


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


From rdroms.ietf@gmail.com  Mon Jul 15 01:14:35 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 04EDC21F9E68 for ; Mon, 15 Jul 2013 01:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4uEpWdvcaRO for ; Mon, 15 Jul 2013 01:14:33 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E1B6221F9E6B for ; Mon, 15 Jul 2013 01:13:58 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id k10so2539330wiv.7 for ; Mon, 15 Jul 2013 01:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6W2evzeEh0moTU2+lT6vaRu9psUfhK04FCeplyAeRys=; b=otLfAozzyrmO/WQ8AXqYUxBrB6HlAgy9i3I9ir1nj8oJ3bpC0Obi6h1ySL+yAuUzyI O2F4FzpWh9z9w86KbMlVBOrZyd0ZHdE/3kWN2S5tQ7udxv4FpAA3rb7794kBOv65eNOV D8CgMeB8Su5UprWvRt2p0vLhuozaxfYvHk5Kmq41KLkyTDewLvdL9pQIPp0faMoRK4sb N041FmxPwkLk9dzsXFiyIXuXQig/oIGGd8M87r4xX2VKc86lV0+S8ev5l4Ao+y26p+G1 dxnw7nu8NYnA3kQaB283DDeDOpvHuUcWYBjaTLulh9iILbeaYdZYC3kQoXFKWBGI9//l SCDw==
X-Received: by 10.180.211.233 with SMTP id nf9mr8040255wic.41.1373876038010; Mon, 15 Jul 2013 01:13:58 -0700 (PDT)
Received: from [10.0.254.71] ([82.110.242.162]) by mx.google.com with ESMTPSA id r8sm19116517wiz.5.2013.07.15.01.13.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 01:13:56 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms 
In-Reply-To: <4094E80F-D17D-452C-9107-6530D36B6DB1@cisco.com>
Date: Mon, 15 Jul 2013 09:13:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <87DF107E-2217-4CFC-BBDF-748B587655DE@gmail.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>  <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com> <51E0300A.4000303@gmail.com> <04BDE310-8E45-466F-B2A0-38A0B78F8ECF@gmail.com>, <51E1C3B2.10300@gmail.com> <4094E80F-D17D-452C-9107-6530D36B6DB1@cisco.com>
To: "Bernie Volz (volz)" , Tomek Mrugalski 
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 15 Jul 2013 08:14:35 -0000

I've submitted -02.  It includes the following changes:

1. range limits on "value" in the options: 60 <=3D "value" <=3D 86400 (1 =
day)
2. options can be included in any server message
3. restructured for options guidelines draft (thanks, Tomek!)
4. expanded security considerations (thanks, Tomek!)
5. in section 5, s/Solicit/Information-request/
6. in IANA considerations, s/an option code/option codes/
7. s/sub-option/encapsulated option/

There's one additional change.  I vaguely recall recent e-mail, perhaps =
from Ted, pointing out that text like this:

      A DHCPv6 client MUST include the INF_MAX_RT option code in an
      Option Request option in any
      message it sends.

      Client also MAY include option SOL_MAX_RT in its SOLICIT,
      REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages as a
      hint for the server regarding preferred option values.

is redundant w.r.t. RFC 3315 and should be omitted.  Makes sense to me, =
so I omitted it from -02.

- Ralph


From internet-drafts@ietf.org  Mon Jul 15 03:57:29 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 3747111E80E1; Mon, 15 Jul 2013 03:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGlUAAjev7Wi; Mon, 15 Jul 2013 03:57:28 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC35021F9FE9; Mon, 15 Jul 2013 03:57:28 -0700 (PDT)
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.51.p2
Message-ID: <20130715105728.22885.17170.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 03:57:28 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-01.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, 15 Jul 2013 10:57:29 -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           : DHCPv4 over DHCPv6 Transport
	Author(s)       : Qi Sun
                          Yong Cui
                          Marcin Siodelski
                          Suresh Krishnan
                          Ian Farrer
	Filename        : draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt
	Pages           : 11
	Date            : 2013-07-15

Abstract:
   This document describes a mechanism for obtaining IPv4 address and
   other parameters in IPv6 networks by carrying DHCPv4 messages over
   DHCPv6 transport.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-dhcpv6-01


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


From msiodelski@gmail.com  Mon Jul 15 04:18: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 9D7C211E80D1 for ; Mon, 15 Jul 2013 04:18:13 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2aZivTKVTio for ; Mon, 15 Jul 2013 04:18:12 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 602B111E80CC for ; Mon, 15 Jul 2013 04:18:12 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id lx15so9156970lab.21 for ; Mon, 15 Jul 2013 04:18:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4ScAnoBAvuXJdwPMcAAm8smolUKhe24zMt0Pivy5Shc=; b=ytVx7336l/MoVwpXc7Afz2Lq70y8IBOprtZP8KnxUIwE/nzm96dymAaskbjFawt0CW I2oOLiEGSYYXHWzLm74Hyv4KI2ECUPSmYaKIOM+VEpu/9U50k+B9MmovOTkCAk37FOvI TYYxuQH0ISairJ3h3Q4A86jlfHGvnXbwZ9pgicbKtghqGRp0/V6JBoryQHHCFHZg6c9+ oEmpoNvKs5tbEOS+Yq0gcUaCK/f80grkADypR1QYC0bv7TZhcNC47TFM/0nWUCQ51JCw BwVKg5+XbpS2drjzsoNkamDQHDE79DqvIjj8zalOFZP//dLyl4asDShHQlA0+1gYE5B5 4B9A==
MIME-Version: 1.0
X-Received: by 10.112.180.164 with SMTP id dp4mr24307629lbc.68.1373887091149;  Mon, 15 Jul 2013 04:18:11 -0700 (PDT)
Received: by 10.112.202.170 with HTTP; Mon, 15 Jul 2013 04:18:11 -0700 (PDT)
In-Reply-To: <20130715105728.22885.17170.idtracker@ietfa.amsl.com>
References: <20130715105728.22885.17170.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 13:18:11 +0200
Message-ID: 
From: Marcin Siodelski 
To: dhcwg@ietf.org
Content-Type: multipart/alternative; boundary=001a11c2650e078ece04e18b047d
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-01.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, 15 Jul 2013 11:18:13 -0000

--001a11c2650e078ece04e18b047d
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

Summary of changes between -00 and -01 of
draft-ietf-dhc-dhcpv4-overs-dhcpv6:

1) Added option sent by the DHCPv6 server to enable DHCPv4-over-DHCPv6 on
the client
2) Added option sent by the DHCPv6 server to instruct a client to use
unicast address of the DHCPv4-over-DHCPv6 servers
3) Renamed 'Unified Server' to '4o6 Server' and define the terms 'DHCP
client' and '4o6 Server' in Terminology
4) Add a new section of 'New DHCPv6 Messages' to specify the newly defined
BOOTREQUESTV6 and BOOTREPLYV6 messages
5) Remove explanations about '4o6 Server' in Architecture Overview (as it
is defined in Terminology)
6) In the section of Client Behavior, specify the transmission of
BOOTREQUESTV6 message follows that in RFC3315.
7) Add reference to the  [draft-ietf-dhc-dhcpv6-unknown-msg-00] in the
section of Relay Agent Behaviors.
8) Specify in the Section of Relay Agent Behavior that Multiple relaying
hops are not considered in the case of separate relay destinations, rather
than 'in the document'.
9) In the section of Server Behavior, specify the transmission of
BOOTREPLYV6 message follows that in RFC3315.

Please review the new version of the document and post your comments.

Cheers,
Marcin


On Mon, Jul 15, 2013 at 12:57 PM,  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           : DHCPv4 over DHCPv6 Transport
>         Author(s)       : Qi Sun
>                           Yong Cui
>                           Marcin Siodelski
>                           Suresh Krishnan
>                           Ian Farrer
>         Filename        : draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt
>         Pages           : 11
>         Date            : 2013-07-15
>
> Abstract:
>    This document describes a mechanism for obtaining IPv4 address and
>    other parameters in IPv6 networks by carrying DHCPv4 messages over
>    DHCPv6 transport.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-dhcpv6-01
>
>
> 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
>

--001a11c2650e078ece04e18b047d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi All,

Summary of changes =
between -00 and -01 of draft-ietf-dhc-dhcpv4-overs-dhcpv6:

1) =
Added option sent by the DHCPv6 server to enable DHCPv4-over-DHCPv6 on the =
client


2) Added option sent by the DHCPv6 server to instruct a client to use =
unicast address of the DHCPv4-over-DHCPv6 servers
3) Renamed 'Unified Server' to &#=
39;4o6 Server' and define the terms 'DHCP client' and '4o6 =
Server' in Terminology


4) Add a new section o=
f 'New DHCPv6 Messages' to specify the newly defined BOOTREQUESTV6 =
and BOOTREPLYV6 messages

5) Remove explanations about '4o6 Server' in Architecture Overview =
(as it is defined in Terminology)
6) In the section of Client Behavior, specify the transmission =
of BOOTREQUESTV6 message follows that in RFC3315.


7) Add reference to the=A0=
=A0[draft-ietf-dhc-dhcpv6-unknown-msg-00]=A0in the section of Relay=A0Agent=
 Behaviors.
8) Spe=
cify in the Section of Relay Agent Behavior that=A0Multiple relaying hops=
=A0are not considered in the case of separate relay destinations, rather th=
an 'in the document'.


9) In the section of Server=
 Behavior, specify=A0the transmission of BOOTREPLYV6 message follows that i=
n RFC3315.


Please review the=
 new version of the document and post your comments.


Cheers,
Marcin


On Mon, J=
ul 15, 2013 at 12:57 PM,  <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 : DHCPv4 over DHCPv6 Transport
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Qi Sun

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yong Cui

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Marcin Siodelski

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Suresh Krishnan

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian Farrer

=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-dhcpv4-over-dhcpv6=
-01.txt

=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11

=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-15



Abstract:

=A0 =A0This document describes a mechanism for obtaining IPv4 address and
=A0 =A0other parameters in IPv6 networks by carrying DHCPv4 messages over
=A0 =A0DHCPv6 transport.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv=
4-over-dhcpv6



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dh=
cpv6-01



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dh=
c-dhcpv4-over-dhcpv6-01





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





--001a11c2650e078ece04e18b047d--

From internet-drafts@ietf.org  Mon Jul 15 05:15:59 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 AF3A521E80AD; Mon, 15 Jul 2013 05:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unYPyiTHZWxe; Mon, 15 Jul 2013 05:15:59 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADE221E809E; Mon, 15 Jul 2013 05:15:59 -0700 (PDT)
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.51.p2
Message-ID: <20130715121559.30301.5493.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 05:15:59 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-design-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, 15 Jul 2013 12:16:00 -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           : DHCPv6 Failover Design
	Author(s)       : Tomasz Mrugalski
                          Kim Kinnear
	Filename        : draft-ietf-dhc-dhcpv6-failover-design-03.txt
	Pages           : 60
	Date            : 2013-07-15

Abstract:
   DHCPv6 defined in [RFC3315] does not offer server redundancy.  This
   document defines a design for DHCPv6 failover, a mechanism for
   running two servers on the same network with capability for either
   server to take over clients' leases in case of server failure or
   network partition.  This is a DHCPv6 Failover design document, it is
   not protocol specification document.  It is a second document in a
   planned series of three documents.  DHCPv6 failover requirements are
   specified in [I-D.ietf-dhc-dhcpv6-failover-requirements].  A protocol
   specification document is planned to follow this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-design

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-design-03


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


From john_brzozowski@cable.comcast.com  Mon Jul 15 05:24: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 2D91611E80F6 for ; Mon, 15 Jul 2013 05:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.368
X-Spam-Level: 
X-Spam-Status: No, score=-104.368 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH0tMY9XAfET for ; Mon, 15 Jul 2013 05:24:22 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 311D011E80E0 for ; Mon, 15 Jul 2013 05:24:22 -0700 (PDT)
Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.82463876; Mon, 15 Jul 2013 06:22:20 -0600
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Mon, 15 Jul 2013 08:24:17 -0400
From: "Brzozowski, John" 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOfu9VKXCYb8bfeUe4+Hi48JV9T5lky14AgADjvAA=
Date: Mon, 15 Jul 2013 12:24:15 +0000
Message-ID: 
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520F98F@mbx-01.win.nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [68.87.16.247]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
To: Ted Lemon , Tomek Mrugalski 
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 15 Jul 2013 12:24:27 -0000

I for one do not feel strongly that that renaming is required.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
o) 609-377-6594
w) www.comcast6.net
e) john_brzozowski@cable.comcast.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D






-----Original Message-----
From: Ted Lemon 
Date: Sunday, July 14, 2013 11:51 AM
To: Tomasz Mrugalski 
Cc: dhc WG , Bernie Volz , Ralph Droms

Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>On Jul 12, 2013, at 7:02 AM, Tomek Mrugalski 
>wrote:
>> I would have named those
>> registries differently, but I suppose there's no procedure (or a real
>> need) to rename them. I think the text in IANA considerations is a bit
>> minimalistic, but correct.
>
>If there is strong desire in the working group to change the name, we can
>do that.   It would require a draft that updates all the specs that use
>that name, including the BOOTP specs.   It might be worth doing; if you
>think it is, feel free to make it happen.
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From tomasz.mrugalski@gmail.com  Mon Jul 15 05:44: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 92DFB21F9E88 for ; Mon, 15 Jul 2013 05:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.378
X-Spam-Level: 
X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQk7aTH-BgP5 for ; Mon, 15 Jul 2013 05:44:39 -0700 (PDT)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C2DA421F9FC9 for ; Mon, 15 Jul 2013 05:44:37 -0700 (PDT)
Received: by mail-bk0-f47.google.com with SMTP id jg1so4556561bkc.34 for ; Mon, 15 Jul 2013 05:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=5n6Rbi8JxdU22EA4W/SITDK7P0P27/4ZCLmrr2fq/bE=; b=X2F1lx4VxX15x1eo4tPC5QhNbw41J9HpQ5u+VHC+Dl9Lo8xqsCgS+LsFdbyGhkurhN lsbjlgfNkzhpLaiqRUcW0itsTtZNUfaGg5h1uFeqQJ97z4EOiWQBNqyT0MyJSVF/aDTT +GiyUPszqVV33bIP4hjZY8CfYAB8FfXfom8t/yDKnLO3/gYuXQAi1y8iv1Eg2jGgfjm9 Oc69bA1Pz53QFx05fkYuI0rCJRiKhkEJ6kLb3QJjL1YfwARsNx4WFSifQbnseERYB9XW 3euYE6AWQLMxTxbWn5RDVnjjN7XY3WjLDShztqQmXmvLzVcsQo4wHSH23yxKqYkrSmTq qaVg==
X-Received: by 10.205.9.8 with SMTP id ou8mr7992514bkb.76.1373892276724; Mon, 15 Jul 2013 05:44:36 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id g5sm4337842bkh.17.2013.07.15.05.44.34 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 05:44:35 -0700 (PDT)
Message-ID: <51E3EEAC.9050304@gmail.com>
Date: Mon, 15 Jul 2013 14:44:28 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ted Lemon ,  "dhcwg@ietf.org WG" 
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com> <51DFE245.6080909@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077520F98F@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520F98F@mbx-01.win.nominum.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130715144428551
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: "Bernie Volz \(volz\)" , Ralph Droms 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
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, 15 Jul 2013 12:44:39 -0000

On 14.07.2013 17:51, Ted Lemon wrote:
> If there is strong desire in the working group to change the name, we
> can do that.   It would require a draft that updates all the specs
> that use that name, including the BOOTP specs.   It might be worth
> doing; if you think it is, feel free to make it happen.
I doubt there's a strong need to do that. It's just an aesthetic detail.

I suppose that's another thing to do as part of the 3315bis work.

From Ted.Lemon@nominum.com  Mon Jul 15 07:23:06 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 CC9F921F9D29 for ; Mon, 15 Jul 2013 07:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.6
X-Spam-Level: 
X-Spam-Status: No, score=-106.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAG6Ax4giy2R for ; Mon, 15 Jul 2013 07:23:00 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id CFD5F1F0D40 for ; Mon, 15 Jul 2013 07:22:35 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUeQFq5vGMd+YAIV4SQ2WxD24t0jZym3U@postini.com; Mon, 15 Jul 2013 07:22:35 PDT
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 5459A1B8243 for ; Mon, 15 Jul 2013 07:22:31 -0700 (PDT)
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 B20E9190052; Mon, 15 Jul 2013 07:22:30 -0700 (PDT) (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, 15 Jul 2013 07:22:30 -0700
From: Ted Lemon 
To: "Gaurav Halwasia (ghalwasi)" 
Thread-Topic: Questions about PD and PD_EXCLUDE
Thread-Index: AQHOgOZ4tJh/uNsHOEGgjsiYWtCCVZllBfnQgAE7C4A=
Date: Mon, 15 Jul 2013 14:22:30 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630775210FD4@mbx-01.win.nominum.com>
References: <8D23D4052ABE7A4490E77B1A012B630775210444@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB230147E7@xmb-aln-x06.cisco.com>
In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB230147E7@xmb-aln-x06.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: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] Questions about PD and PD_EXCLUDE
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, 15 Jul 2013 14:23:07 -0000

On Jul 14, 2013, at 7:37 PM, "Gaurav Halwasia (ghalwasi)"  wrote:
> Implementations which I work on and aware of shall add the route for both=
 the IA_PD's. What do you mean by "wrong thing" exactly.?

Not routing for both IA_PDs would be the "wrong thing."   Good to know, tha=
nks!


From Ted.Lemon@nominum.com  Mon Jul 15 07:30: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 A445611E8143 for ; Mon, 15 Jul 2013 07:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.6
X-Spam-Level: 
X-Spam-Status: No, score=-106.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORE-COMRLait for ; Mon, 15 Jul 2013 07:30:14 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3157B11E8106 for ; Mon, 15 Jul 2013 07:29:48 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUeQHW+PvXyoOtMUN0NmqUn+gm7v3n9jq@postini.com; Mon, 15 Jul 2013 07:29:48 PDT
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 D0D411B8230 for ; Mon, 15 Jul 2013 07:29:47 -0700 (PDT)
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 C8AD4190052 for ; Mon, 15 Jul 2013 07:29:47 -0700 (PDT) (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, 15 Jul 2013 07:29:48 -0700
From: Ted Lemon 
To: "dhcwg@ietf.org WG" 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-02.txt
Thread-Index: AQHOgTNwlJXg6PrZ8EeMRAvWPY4iTZlmQnWA
Date: Mon, 15 Jul 2013 14:29:47 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752110A6@mbx-01.win.nominum.com>
References: <20130715081351.12597.80962.idtracker@ietfa.amsl.com>
In-Reply-To: <20130715081351.12597.80962.idtracker@ietfa.amsl.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: <33CF0D662EDBD045974ECFC38B847A8F@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-02.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, 15 Jul 2013 14:30:24 -0000

I like the new version, but the requirements language for min and max value=
s needs to be enforced in the Client Behavior section:

   The client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT values
   that are less than 60 or more than 86400.

Otherwise the stated limits are somewhat toothless... :)


From Ted.Lemon@nominum.com  Mon Jul 15 07:36: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 8C13711E8138 for ; Mon, 15 Jul 2013 07:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.6
X-Spam-Level: 
X-Spam-Status: No, score=-106.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf3bcSl9UEyq for ; Mon, 15 Jul 2013 07:36:39 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C9DEE11E8131 for ; Mon, 15 Jul 2013 07:36:39 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUeQI97MpuiJgc7C0om7VMSJWuXSDuIMC@postini.com; Mon, 15 Jul 2013 07:36:39 PDT
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 73D7F1B8243 for ; Mon, 15 Jul 2013 07:36:39 -0700 (PDT)
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 69C17190052; Mon, 15 Jul 2013 07:36:39 -0700 (PDT) (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, 15 Jul 2013 07:36:39 -0700
From: Ted Lemon 
To: Ralph Droms 
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4
Thread-Index: AQHOgTN2u8X/a3xC+Ey2Zd4XM7ClsZlmRF4A
Date: Mon, 15 Jul 2013 14:36:38 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630775211198@mbx-01.win.nominum.com>
References:  <79A85A7E-350C-4528-922D-485F92E2E537@gmail.com> <489D13FBFA9B3E41812EA89F188F018E185DE1E8@xmb-rcd-x04.cisco.com>, <51DFE245.6080909@gmail.com>  <7D967065-54FC-404E-A740-5CD0A9868B52@gmail.com> <51E007ED.7010105@gmail.com> <71D9A8C2-267F-4C01-94BA-CD6657DD76F9@gmail.com> <51E01A27.1040409@gmail.com>  <489D13FBFA9B3E41812EA89F188F018E185E09BB@xmb-rcd-x04.cisco.com> <51E0300A.4000303@gmail.com> <04BDE310-8E45-466F-B2A0-38A0B78F8ECF@gmail.com>, <51E1C3B2.10300@gmail.com> <4094E80F-D17D-452C-9107-6530D36B6DB1@cisco.com> <87DF107E-2217-4CFC-BBDF-748B587655DE@gmail.com>
In-Reply-To: <87DF107E-2217-4CFC-BBDF-748B587655DE@gmail.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: <2E370DE727D1F346BBB54BC070E3277B@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -	respond by July 4
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, 15 Jul 2013 14:36:46 -0000

On Jul 15, 2013, at 1:13 AM, Ralph Droms  wrote:
> is redundant w.r.t. RFC 3315 and should be omitted.  Makes sense to me, s=
o I omitted it from -02.

Thanks.   Personally, I think we should delete that text from 3315 as well.=
   I don't know of any server that implements this behavior, and I don't un=
derstand why it would be useful.   If the client already knows what to do, =
why ask the server at all?


From wesley.george@twcable.com  Mon Jul 15 08:16:01 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 16F5221E8085 for ; Mon, 15 Jul 2013 08:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.526
X-Spam-Level: 
X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riBFqNOYAV6f for ; Mon, 15 Jul 2013 08:15:57 -0700 (PDT)
Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id B195221E804D for ; Mon, 15 Jul 2013 08:15:56 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.89,669,1367985600"; d="scan'208,217";a="33668700"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Jul 2013 11:15:40 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 15 Jul 2013 11:15:55 -0400
From: "George, Wes" 
To: "dhcwg@ietf.org" 
Date: Mon, 15 Jul 2013 11:15:54 -0400
Thread-Topic: Sunset4/DHC joint meeting, Wednesday Session III
Thread-Index: Ac6BbdUQ+RUEhhZXTxWpO1ZYEn7g6gAAEwgw
Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043882B62C@PRVPEXVS15.corp.twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD5923043882B62CPRVPEXVS15cor_"
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 15 Jul 2013 09:11:27 -0700
Subject: [dhcwg] FW: Sunset4/DHC joint meeting, Wednesday Session III
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, 15 Jul 2013 15:16:01 -0000

--_000_2671C6CDFBB59E47B64C10B3E0BD5923043882B62CPRVPEXVS15cor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Now with correct email address for DHC... Sigh.

Thanks,

Wes

From: George, Wes
Sent: Monday, July 15, 2013 11:13 AM
To: sunset4@ietf.org; 'dhc@ietf.org'
Cc: sunset4-chairs@tools.ietf.org; dhc-chairs@tools.ietf.org; int-ads@tools=
.ietf.org; draft-ietf-dhc-dhcpv4-over-ipv6@tools.ietf.org; 'draft-ietf-dhc-=
v4configuration@tools.ietf.org'; 'draft-wing-dhc-dns-reconfigure@tools.ietf=
.org'; draft-perreault-sunset4-noipv4@tools.ietf.org
Subject: Sunset4/DHC joint meeting, Wednesday Session III

All -

There will be a joint meeting at IETF 87 between Sunset4 and DHC from 1620-=
1720 Wednesday (the second hour of Sunset4's meeting time). The chairs of b=
oth groups and the IntArea ADs met at IETF in Orlando to discuss the potent=
ial overlap between some work going on in DHC (provisioning IPv4 over IPv6 =
or DHCPv4 over DHCPv6) and some work going on in Sunset4 to govern signalin=
g end networks and hosts about the absence or presence of IPv4 connectivity=
, as well as preferences about which address family to use for which set of=
 traffic. We agreed that it would be useful to discuss these things togethe=
r, to ensure that we are coordinating well between the groups' efforts, as =
well as to get a wider group of people thinking about the combined problem =
set and reviewing the associated drafts.

Based on those initial discussions, the chairs have identified a few drafts=
 that are of interest to both groups, and that is what generated the draft =
agenda for the meeting.
The meeting materials, including the agenda, and  an introduction slide dec=
k discussing the goals of the joint session are available for review under =
Sunset4's meeting materials area.
Agenda: http://www.ietf.org/proceedings/87/agenda/agenda-87-sunset4 (see se=
cond half)
Intro Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-sun=
set4-0.pdf

Please review and bash, especially if you feel after reviewing the intro sl=
ides that there are additional drafts that should be discussed. The timeslo=
ts for discussing the listed drafts are not intended to be a full introduct=
ion of the draft for those unfamiliar with it. Rather, this is meant to be =
the point at which we discuss the interaction between the two groups and co=
ordination of changes to DHCP as proposed. We encourage the authors to put =
together a one slide summary, along with a slide or two with discussion que=
stions.

Thanks,

Wes George, Sunset4 co-chair

Anything below this line has been added by my company's mail server, I have=
 no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_2671C6CDFBB59E47B64C10B3E0BD5923043882B62CPRVPEXVS15cor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Now with correct email=
 address for DHC… Sigh.


 




Thank=
s,


=
 


Wes


 








From: George, =
Wes


Sent: Monday, July 15, 2013 11:13 AM

To: sunset4@ietf.org; 'dhc@ietf.org'

Cc: sunset4-chairs@tools.ietf.org; dhc-chairs@tools.ietf.org; int-ad=
s@tools.ietf.org; draft-ietf-dhc-dhcpv4-over-ipv6@tools.ietf.org; 'draft-ie=
tf-dhc-v4configuration@tools.ietf.org'; 'draft-wing-dhc-dns-reconfigure@too=
ls.ietf.org'; draft-perreault-sunset4-noipv4@tools.ietf.org

Subject: Sunset4/DHC joint meeting, Wednesday Session III=







 


All – 


 


There will be a joint meeting at IETF 87 between Sun=
set4 and DHC from 1620-1720 Wednesday (the second hour of Sunset4’s m=
eeting time). The chairs of both groups and the IntArea ADs met at IETF in =
Orlando to discuss the potential overlap
 between some work going on in DHC (provisioning IPv4 over IPv6 or DHCPv4 o=
ver DHCPv6) and some work going on in Sunset4 to govern signaling end netwo=
rks and hosts about the absence or presence of IPv4 connectivity, as well a=
s preferences about which address
 family to use for which set of traffic. We agreed that it would be useful =
to discuss these things together, to ensure that we are coordinating well b=
etween the groups’ efforts, as well as to get a wider group of people=
 thinking about the combined problem set
 and reviewing the associated drafts. 


 


Based on those initial discussions, the chairs have =
identified a few drafts that are of interest to both groups, and that is wh=
at generated the draft agenda for the meeting.



The meeting materials, including the agenda, and&nbs=
p; an introduction slide deck discussing the goals of the joint session are=
 available for review under Sunset4’s meeting materials area.



Agenda: 
http://www.ietf.org/proceedings/87/agenda/agenda-87-sunset4 (see second=
 half)


Intro Presentation: 
http://www.ietf.org/proceedings/87/slides/slides-87-sunset4-0.pdf<=
/o:p>


 


Please review and bash, especially if you feel after=
 reviewing the intro slides that there are additional drafts that should be=
 discussed. The timeslots for discussing the listed drafts are not intended=
 to be a full introduction of the
 draft for those unfamiliar with it. Rather, this is meant to be the point =
at which we discuss the interaction between the two groups and coordination=
 of changes to DHCP as proposed. We encourage the authors to put together a=
 one slide summary, along with a
 slide or two with discussion questions.


 


Thanks,


 


Wes George, Sunset4 co-chair


 


Anything below this li=
ne has been added by my company’s mail server, I have no control over=
 it.


-----------=








This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.





--_000_2671C6CDFBB59E47B64C10B3E0BD5923043882B62CPRVPEXVS15cor_--

From tomasz.mrugalski@gmail.com  Mon Jul 15 09:16: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 8E37911E8185 for ; Mon, 15 Jul 2013 09:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.392
X-Spam-Level: 
X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYeurs9yt3ws for ; Mon, 15 Jul 2013 09:16:08 -0700 (PDT)
Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E311E817B for ; Mon, 15 Jul 2013 09:15:46 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id 6so4765767bkj.31 for ; Mon, 15 Jul 2013 09:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=OK3c84vxm04A4Z9FL6C6bdGU74ttiidN70BDrnUhRA8=; b=Sk+0Tk1kulxmhV4j6db5FcUCxV/PXBHNb17sRkNlE4C2KiYVWjOSNzws0RArcSm3jp +n8R+46UxbZCEYWz4UbbmUYND4fhjjlYfVP9vwZNqEg/jtgghfaJ48qQXYqMPsrUoo62 WrZVTDjxruquLHbVx8EXqftoQBM2jAlFrLa7bhu1h2v+6OWZ/8Id6F3a8SljibPx3OiH ZmZL22LkM13DVyj7biixlwyUU5AJSNS1kK1M2R52xZpe8vjx819iaTBFDdGH5lAEwc3T cBuuRiRofpI8ukWnQABODBw2m2uMp6a7So/pLIYpOyxVmYeHZjMaI5hVHhliGJmTW8rD 0/5g==
X-Received: by 10.204.70.1 with SMTP id b1mr8076443bkj.3.1373904945243; Mon, 15 Jul 2013 09:15:45 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id g5sm4673241bkh.17.2013.07.15.09.15.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 09:15:44 -0700 (PDT)
Message-ID: <51E42029.4070902@gmail.com>
Date: Mon, 15 Jul 2013 18:15:37 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Bernie Volz (volz)" 
References: <20130715121559.30301.5493.idtracker@ietfa.amsl.com>
In-Reply-To: <20130715121559.30301.5493.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130715181537351
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org, Kim Kinnear 
Subject: [dhcwg] Requesting WGLC for draft-ietf-dhc-dhcpv6-failover-design-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, 15 Jul 2013 16:16:08 -0000

Finally, Kim and I found some time to revive this draft. It hopefully
addresses all comments received since it was presented in Atlanta. In
our opinion, the draft is ready. As I'm co-author of this drafts, I'd
like to ask Bernie to announce WGLC and later gauge consensus on this work.

Thanks,
Tomek

On 15.07.2013 14:15, internet-drafts@ietf.org 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           : DHCPv6 Failover Design
> 	Author(s)       : Tomasz Mrugalski
>                           Kim Kinnear
> 	Filename        : draft-ietf-dhc-dhcpv6-failover-design-03.txt
> 	Pages           : 60
> 	Date            : 2013-07-15
> 
> Abstract:
>    DHCPv6 defined in [RFC3315] does not offer server redundancy.  This
>    document defines a design for DHCPv6 failover, a mechanism for
>    running two servers on the same network with capability for either
>    server to take over clients' leases in case of server failure or
>    network partition.  This is a DHCPv6 Failover design document, it is
>    not protocol specification document.  It is a second document in a
>    planned series of three documents.  DHCPv6 failover requirements are
>    specified in [I-D.ietf-dhc-dhcpv6-failover-requirements].  A protocol
>    specification document is planned to follow this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-design
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-design-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 wwwrun@rfc-editor.org  Wed Jul 17 12:14: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 25CBC21E8087; Wed, 17 Jul 2013 12:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.945
X-Spam-Level: 
X-Spam-Status: No, score=-101.945 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHhuskD+5G3K; Wed, 17 Jul 2013 12:14:41 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 876EC21E8064; Wed, 17 Jul 2013 12:14:39 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D90848E019; Wed, 17 Jul 2013 12:12:00 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130717191200.D90848E019@rfc-editor.org>
Date: Wed, 17 Jul 2013 12:12:00 -0700 (PDT)
Cc: drafts-update-ref@iana.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org
Subject: [dhcwg] RFC 6977 on Triggering DHCPv6 Reconfiguration from Relay Agents
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, 17 Jul 2013 19:14:42 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6977

        Title:      Triggering DHCPv6 Reconfiguration from Relay 
                    Agents 
        Author:     M. Boucadair, X. Pougnard
        Status:     Standards Track
        Stream:     IETF
        Date:       July 2013
        Mailbox:    mohamed.boucadair@orange.com, 
                    xavier.pougnard@orange.com
        Pages:      13
        Characters: 29769
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dhc-triggered-reconfigure-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6977.txt

This document defines two new DHCPv6 messages: Reconfigure-Request
and Reconfigure-Reply.  The 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.  The Reconfigure-Reply message is used by the
server to acknowledge the receipt of the Reconfigure-Request message.

This document is a product of the Dynamic Host Configuration Working Group of the IETF.

This is now a Proposed Standard.

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/search/rfc_search.php
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 volz@cisco.com  Thu Jul 18 19:53: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 E085521F99F8 for ; Thu, 18 Jul 2013 19:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEyFU47XcGGI for ; Thu, 18 Jul 2013 19:53:39 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 98E3221F9AFD for ; Thu, 18 Jul 2013 19:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7068; q=dns/txt; s=iport; t=1374202410; x=1375412010; h=from:to:subject:date:message-id:mime-version; bh=PmIbTGRMMKl9xTJls4LqBfIumMoqlECNurJdNrwXkKM=; b=ChDa8nDdEsSMasNk086kmQYLpmgNZd7Pm4S9HaPWhDfCBx8e8bKhOF87 7O4dUnosoHNLsJALK3egRQ4/q2zkm4CrWIgDScm29z0rd3DbUIeo61P+R DTIUSnSTE6YGYuvLQj98giHgUCPYUdOB5NNTiCiCVbiGhogYO0lTWG8DR 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAGip6FGtJV2d/2dsb2JhbABagkJENVC4B4g8gRQWdIImAQQtXgEqHTkUEgEEEwiICAyWAKBEj14tCoMPbgOZBpAkgxKCKg
X-IronPort-AV: E=Sophos;i="4.89,698,1367971200";  d="scan'208,217";a="236767398"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jul 2013 02:53:30 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6J2rUht007377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 02:53:30 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 21:53:29 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: Berlin IETF - Scribe needed! & Slides Reminder
Thread-Index: Ac6EKlMEna3Gbb1kSwuxPruEBy0rFg==
Date: Fri, 19 Jul 2013 02:53:29 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185EBC3E@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.86.247.75]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185EBC3Exmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] Berlin IETF - Scribe needed! & Slides Reminder
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, 19 Jul 2013 02:53:48 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185EBC3Exmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:

We need a scribe for taking notes for the minutes. We suggest use of etherp=
ad, but any form is fine. See http://tools.ietf.org/wg/dhc/minutes.

If you'll be at the Berlin session, we'd greatly appreciate if you'd volunt=
eer to take notes for the minutes.

And please let us know in advance!


Also, if you have slides, please provide them to us (dhc-chairs@tools.ietf.=
org) so we can get them posted.

Updated agenda and a few of the presentations have been posted. See https:/=
/datatracker.ietf.org/meeting/87/agenda/dhc/ and https://datatracker.ietf.o=
rg/meeting/87/materials.html#wg-dhc.


-          Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E185EBC3Exmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi:


 


We need a scribe for taking notes for the minutes. W=
e suggest use of etherpad, but any form is fine. See
http://tools.ietf.org/wg/d=
hc/minutes.


 


If you’ll be at the Berlin session, we̵=
7;d greatly appreciate if you’d volunteer to take notes for the minut=
es.




 <=
/p>

And please let us =
know in advance!


 <=
/p>



 


Also, if you have slides, please provide them to us =
(dhc-chairs@tools.ietf.org=
) so we can get them posted.


 


Updated agenda and a few of the presentations have b=
een posted. See
https://dat=
atracker.ietf.org/meeting/87/agenda/dhc/ and
h=
ttps://datatracker.ietf.org/meeting/87/materials.html#wg-dhc.


 


-     &=
nbsp;   
Bernie






--_000_489D13FBFA9B3E41812EA89F188F018E185EBC3Exmbrcdx04ciscoc_--

From volz@cisco.com  Fri Jul 19 06:59:26 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 2873D11E81E6 for ; Fri, 19 Jul 2013 06:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.573
X-Spam-Level: 
X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSzjR08hDySI for ; Fri, 19 Jul 2013 06:59:21 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 25A8011E8142 for ; Fri, 19 Jul 2013 06:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7514; q=dns/txt; s=iport; t=1374242361; x=1375451961; h=from:to:subject:date:message-id:mime-version; bh=DUTLNA6qS9SdcycvUrDjN7OUCyUo6jBraoZgizldcqc=; b=PVV1LpoLjGvBEhty052PccM9lRhr7CKptyHI1OC/USNmvTJ9z+kSWxrt ai97GqPibs48i+nzJAciSsKCgLgzkNOWE3tNaI+w5LQ6qtGsrZNnZs2CS pAj8hHgVl4xTsiYwSHq/rrjFTaEoVPsMRkHsl+dGvB62k53ETA1O3aSwh M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmAFAL1F6VGtJXG9/2dsb2JhbABbgkJENVC4Cog8gQ8WdIImAQQtXgEqViYBBBuICAyWQ6BJj16DSG4DmQaQJIMSgio
X-IronPort-AV: E=Sophos;i="4.89,701,1367971200";  d="scan'208,217";a="236927724"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jul 2013 13:59:20 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6JDxK9i023916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 13:59:20 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 08:59:20 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
Thread-Index: Ac6Eh+GxcVMnIa4YTCqgEkgg655xbg==
Date: Fri, 19 Jul 2013 13:59:20 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@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.86.247.75]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185ECB4Bxmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 19 Jul 2013 13:59:26 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185ECB4Bxmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 (http://tool=
s.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) believe it is ready =
for working group last call. Please review this draft and indicate whether =
or not you feel it is ready to be published. Your input is important!



This document is the 2nd series of documents related to DHCPv6 failover - t=
he first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requi=
rements which is currently being reviewed by the IESG for publication appro=
val.



At the time of this writing, there is no IPR reported against this draft.



As Tomek is a co-author, I will primarily evaluate consensus after 2013-08-=
09 (August 9th). This is a 3 week last call because of the Berlin IETF meet=
ing and also because of summer-time vacations (at least for those of us in =
the northern hemisphere).



Thanks,


-          Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E185ECB4Bxmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Folks, the authors of draft-ietf-dhc-dhcpv6-failo=
ver-design-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-=
design) believe it is ready for
 working group last call. Please review this draft and indicate whether or =
not you feel it is ready to be published. Your input is important!


 


This document is the 2nd series of doc=
uments related to DHCPv6 failover – the first is

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements =
which is currently being reviewed by the IESG for publication approval.


 


At the time of this writing, there is no IPR repo=
rted against this draft.


 


As Tomek is a co-author, I will primarily evaluat=
e consensus after 2013-08-09 (August 9th). This is a 3 week last=
 call because of the Berlin IETF meeting and also because of summer-time va=
cations (at least for those of us
 in the northern hemisphere).


 


Thanks,


 


-     &=
nbsp;   
Bernie






--_000_489D13FBFA9B3E41812EA89F188F018E185ECB4Bxmbrcdx04ciscoc_--

From volz@cisco.com  Fri Jul 19 09:20: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 87D6011E8151 for ; Fri, 19 Jul 2013 09:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PED39DTuKyD for ; Fri, 19 Jul 2013 09:20:05 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8053211E8145 for ; Fri, 19 Jul 2013 09:20:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13572; q=dns/txt; s=iport; t=1374250805; x=1375460405; h=from:to:subject:date:message-id:mime-version; bh=8sipRnKUPsz+ULybPU3HDvcz38KHUDSU2zLQ1yZJiAo=; b=LNNVCGc7gmeGJLrltcA5yf2OzAH9dKxP53nWGbyo8q06H3oLz82nVwwk qaBjMVc+IVGwSQowLGU7O9477qVQO2bOAr7wpHR/4xGkBLRUyaQf3PByw Ot0o7iDBvBNNvaT+HF9fsiQT4Kj9btUhbeimo6Emv+7Bvs2rb8PeY73nT Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmIFABFm6VGtJXG+/2dsb2JhbABbgkJENVC4DYg8gRAWdIIkAQEBBB0QXgEZBAEBCx05FAkJAQQTCAGIBwyWMKBJjk0QgQE3gxFuA5kGkCSDEoFxOQ
X-IronPort-AV: E=Sophos;i="4.89,702,1367971200";  d="scan'208,217";a="236999659"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2013 16:20:05 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JGK42c024176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 16:20:04 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 11:20:04 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: WGLC Results for draft-ietf-dhc-option-guidelines-12
Thread-Index: Ac6Em3I0GX5nfeX5QBaddUv4K//Mag==
Date: Fri, 19 Jul 2013 16:20:03 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E185ED233@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.86.243.155]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E185ED233xmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] WGLC Results for draft-ietf-dhc-option-guidelines-12
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, 19 Jul 2013 16:20:10 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E185ED233xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:

Based on my records, there appears to have only been one set of comments by=
 Ralph, regarding the use of fragment/fragment types and referencing RFC 21=
31 (2132). See http://www.ietf.org/mail-archive/web/dhcwg/current/msg14476.=
html  (I and Ralph exchanged an email his issues too).

As this last call was just to confirm that recent changes were acceptable, =
I'll assume they are (excepting Ralph's comments), as we had an extensive r=
eview of the -11 document (via the WGLC).

The authors are asked to respond to Ralph's comments by either updating the=
 draft (-13) or to indicate why they do not agree to Ralph's comments. And,=
 once that is done I will initiate the write up and send this document to t=
he IESG (via the AD).

Note: A -13 will of course need to wait until submissions reopen.


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B=
ernie Volz (volz)
Sent: Monday, July 01, 2013 5:44 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respond by Ju=
ly 15


The draft-ietf-dhc-option-guidelines-12, http://tools.ietf.org/html/draft-i=
etf-dhc-option-guidelines-12, addresses the comments from the previous (-11=
) last call. While originally I expected to have a short (1 week) last call=
 for the updated document, I think it best to have the standard 2 weeks giv=
en the time of year (and the Independence Day holiday in the US).



Please review the draft and indicate whether or not you feel this version i=
s ready to be published. Your response matters to the process, so please do=
 respond.



Do note: While I encourage full reviews, the main focus is to assure we hav=
e consensus on the recent changes from the -11. The -11 WGLC support will b=
e taken into consideration.



As Tomek is an author, I will evaluate consensus after July 15, 2013.



-          Bernie



--_000_489D13FBFA9B3E41812EA89F188F018E185ED233xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi:<=
/p>

 


Based on my records, t=
here appears to have only been one set of comments by Ralph, regarding the =
use of fragment/fragment types and referencing RFC 2131 (2132). See
http://www.ietf.org/mail-archive/web/dhcwg/current/msg14476.html  (I and Ralph exchanged an email his =
issues too).


 


As this last call was =
just to confirm that recent changes were acceptable, I’ll assume they=
 are (excepting Ralph’s comments), as we had an extensive review of t=
he -11 document (via the WGLC).


 


The authors are asked =
to respond to Ralph’s comments by either updating the draft (-13) or =
to indicate why they do not agree to Ralph’s comments. And, once that=
 is done I will initiate the write up and send this
 document to the IESG (via the AD).


 


Note: A -13 will of co=
urse need to wait until submissions reopen.


 


-&nb=
sp;        
Bernie


 






From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Bernie Volz (volz)

Sent: Monday, July 01, 2013 5:44 PM

To: dhcwg@ietf.org

Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-12 - Respon=
d by July 15






 


The draft-ietf-dhc-option-guidelines-12, 
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-12, address=
es the comments from the previous (-11) last call. While originally I expec=
ted to have a short (1 week) last call for the updated document, I think it=
 best to have the standard 2 weeks
 given the time of year (and the Independence Day holiday in the US).<=
/o:p>


 


Please review the draft and indicate whether or n=
ot you feel this version is ready to be published. Your response matters to=
 the process, so please do respond.


 


Do note: While I encourage full reviews, the m=
ain focus is to assure we have consensus on the recent changes from the -11=
. The -11 WGLC support will be taken into consideration.


 


As Tomek is an author, I will evaluate consensus =
after July 15, 2013.


 



-       =
;  
Bernie


 






--_000_489D13FBFA9B3E41812EA89F188F018E185ED233xmbrcdx04ciscoc_--

From tomasz.mrugalski@gmail.com  Fri Jul 26 08:43: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 D739521F93E1 for ; Fri, 26 Jul 2013 08:43:08 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGQsTXG4fpFK for ; Fri, 26 Jul 2013 08:43:08 -0700 (PDT)
Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B1BDC21F93D4 for ; Fri, 26 Jul 2013 08:42:57 -0700 (PDT)
Received: by mail-bk0-f53.google.com with SMTP id e11so1177758bkh.26 for ; Fri, 26 Jul 2013 08:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=xVE3pUpJqylIS9sFyfncFKPfK46x4Ma83AVLPh8NOGw=; b=y7BCgLLyHRUnLp3hr9ndTygDIwOydEFuTUoQoDIU/SO7SZC4GLJGTJHwsOvV2ygCKk yYcod19WWOqKqHLl+Gal5QLzpHWignR9ahmsruPsQSXJd/1FHioK7bSGtQ9+4Q4D7NBx acUeu1yUlyYj8L8DK/jhMVOEZBhi7AVHuLRhleOUs2AsAJ0e7cyuFLMbb1jH18Wz3tjR x9R6IOn9zhTraHkalJgFziSTexPeRqC9w2avkDvFUV+Kx29W7gSv3tqPMhf8ZoelZ6PL elwXpEybthmu/yhDmnqCvZnvmqUDlghdO7vMiFrYEqjhwajPNJmg2ajhDaVKopWQkv7B xrmg==
X-Received: by 10.204.233.14 with SMTP id jw14mr2221331bkb.159.1374853376788;  Fri, 26 Jul 2013 08:42:56 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id px7sm12632254bkb.9.2013.07.26.08.42.54 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 08:42:55 -0700 (PDT)
Message-ID: <51F298FD.3090009@gmail.com>
Date: Fri, 26 Jul 2013 17:42:53 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "dhcwg@ietf.org" 
References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130726174253221
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 26 Jul 2013 15:43:09 -0000

On 19.07.2013 15:59, Bernie Volz (volz) wrote:
> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
> believe it is ready for working group last call. Please review this
> draft and indicate whether or not you feel it is ready to be published.
> Your input is important!
I support this work moving forward. It doesn't count much, as I'm co-author.

I'm somewhat disappointed with the complete lack of any comments. When
we started the work on v6 failover, there was exactly 20 people
expressing their interest in this work that wanted to join the the
effort. A year and a half passed and now there seems to be noone to even
say "yeah, it's ok".

A week has passed for this WGLC already. WGLC will end in 2 weeks, so
there's still plenty of time for a through review. If you want to have
v6 failover, respond. Make no mistake - without sufficient support, this
work will fail WGLC.

If you have time - please review it. If you are busy or just don't care
about the details, saying that you support this work is useful and you
want it to move forward is helpful, too.

Tomek


From stenc@s-carlsen.dk  Fri Jul 26 09:39: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 6779E21F9AAB for ; Fri, 26 Jul 2013 09:39:16 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuXONf0xGjcK for ; Fri, 26 Jul 2013 09:39:12 -0700 (PDT)
Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5680521F9A87 for ; Fri, 26 Jul 2013 09:39:09 -0700 (PDT)
Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 372408E5B for ; Fri, 26 Jul 2013 18:39:05 +0200 (CEST)
Message-ID: <51F2A629.3060001@s-carlsen.dk>
Date: Fri, 26 Jul 2013 18:39:05 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> <51F298FD.3090009@gmail.com>
In-Reply-To: <51F298FD.3090009@gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------080109050306040306060601"
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 26 Jul 2013 16:39:16 -0000

This is a multi-part message in MIME format.
--------------080109050306040306060601
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I have not had the time to read the proposal yet, I believe it is useful
to have failover available for larger installations.

So, please don't drop it.


On 26/07/13 17:42, Tomek Mrugalski wrote:
> On 19.07.2013 15:59, Bernie Volz (volz) wrote:
>> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
>> believe it is ready for working group last call. Please review this
>> draft and indicate whether or not you feel it is ready to be published.
>> Your input is important!
> I support this work moving forward. It doesn't count much, as I'm co-author.
>
> I'm somewhat disappointed with the complete lack of any comments. When
> we started the work on v6 failover, there was exactly 20 people
> expressing their interest in this work that wanted to join the the
> effort. A year and a half passed and now there seems to be noone to even
> say "yeah, it's ok".
>
> A week has passed for this WGLC already. WGLC will end in 2 weeks, so
> there's still plenty of time for a through review. If you want to have
> v6 failover, respond. Make no mistake - without sufficient support, this
> work will fail WGLC.
>
> If you have time - please review it. If you are busy or just don't care
> about the details, saying that you support this work is useful and you
> want it to move forward is helpful, too.
>
> Tomek
>
> _______________________________________________
> 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!!!" 


--------------080109050306040306060601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I have not had the time to read the proposal yet, I believe it is
    useful to have failover available for larger installations.

    

    So, please don't drop it.

    

    

    
On 26/07/13 17:42, Tomek Mrugalski
      wrote:

    

    

      
On 19.07.2013 15:59, Bernie Volz (volz) wrote:


      

        
Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
believe it is ready for working group last call. Please review this
draft and indicate whether or not you feel it is ready to be published.
Your input is important!


      

      
I support this work moving forward. It doesn't count much, as I'm co-author.

I'm somewhat disappointed with the complete lack of any comments. When
we started the work on v6 failover, there was exactly 20 people
expressing their interest in this work that wanted to join the the
effort. A year and a half passed and now there seems to be noone to even
say "yeah, it's ok".

A week has passed for this WGLC already. WGLC will end in 2 weeks, so
there's still plenty of time for a through review. If you want to have
v6 failover, respond. Make no mistake - without sufficient support, this
work will fail WGLC.

If you have time - please review it. If you are busy or just don't care
about the details, saying that you support this work is useful and you
want it to move forward is helpful, too.

Tomek

_______________________________________________
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!!!" 


  


--------------080109050306040306060601--

From sthaug@nethelp.no  Fri Jul 26 09:58:03 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 E87CF11E811A for ; Fri, 26 Jul 2013 09:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OHxG7-bXhx4 for ; Fri, 26 Jul 2013 09:57:59 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 98D6921F9A7D for ; Fri, 26 Jul 2013 09:57:47 -0700 (PDT)
Received: (qmail 99647 invoked from network); 26 Jul 2013 16:57:45 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 26 Jul 2013 16:57:45 -0000
Date: Fri, 26 Jul 2013 18:57:45 +0200 (CEST)
Message-Id: <20130726.185745.112538871.sthaug@nethelp.no>
To: stenc@s-carlsen.dk
From: sthaug@nethelp.no
In-Reply-To: <51F2A629.3060001@s-carlsen.dk>
References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> <51F298FD.3090009@gmail.com> <51F2A629.3060001@s-carlsen.dk>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 26 Jul 2013 16:58:04 -0000

> I have not had the time to read the proposal yet, I believe it is useful
> to have failover available for larger installations.
> 
> So, please don't drop it.

Same thing here. I'm on vacation with rather poor Internet access
(happens to be the U.S., but that's another discussion). I'm very
definitely interested in this draft.

Steinar Haug, AS 2116

> 
> On 26/07/13 17:42, Tomek Mrugalski wrote:
> > On 19.07.2013 15:59, Bernie Volz (volz) wrote:
> >> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
> >> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
> >> believe it is ready for working group last call. Please review this
> >> draft and indicate whether or not you feel it is ready to be published.
> >> Your input is important!
> > I support this work moving forward. It doesn't count much, as I'm co-author.
> >
> > I'm somewhat disappointed with the complete lack of any comments. When
> > we started the work on v6 failover, there was exactly 20 people
> > expressing their interest in this work that wanted to join the the
> > effort. A year and a half passed and now there seems to be noone to even
> > say "yeah, it's ok".
> >
> > A week has passed for this WGLC already. WGLC will end in 2 weeks, so
> > there's still plenty of time for a through review. If you want to have
> > v6 failover, respond. Make no mistake - without sufficient support, this
> > work will fail WGLC.
> >
> > If you have time - please review it. If you are busy or just don't care
> > about the details, saying that you support this work is useful and you
> > want it to move forward is helpful, too.
> >
> > Tomek
> >
> > _______________________________________________
> > 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!!!" 
> 

From gvithal@gmail.com  Fri Jul 26 10:48:03 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 CF99A21F8756 for ; Fri, 26 Jul 2013 10:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+K0kBSAKxsH for ; Fri, 26 Jul 2013 10:48:02 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2687311E8114 for ; Fri, 26 Jul 2013 10:48:00 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f12so2473917wgh.15 for ; Fri, 26 Jul 2013 10:48:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=5HGrW9tewqM/OGJ44gYhq2AZZQFG+6r0YZMc3bfDIjc=; b=uWv7dikKk7tCgitH3f/emvMi30NUk5zcbQDeokD7JUC4GCyv332Yrsj5MNEKmRRDOJ QCj/qQXWePQOJkDOefA+K1QHqUVqrrqXvhWLO2oz6uuEKufC7rban888HMwFgVZQE+gC 4AFvknCwwRXiZ//sbph3vTFY50bbqqOAIsa970dTcaRze9e62U+clCgOyI8t5P41pCmd IB2c/CYi5gdI+UFj0r5XXF6PRyX/0WsFdgHnsxwjbaPRlPlk7J4HtWiDEMcPFeoeK73T BfZRhY8GaSjs+EMmV+Z8SKGcp4KMG7McYzsRtxgFdhRkme9hfCc4wnd88kZharFEYzp6 gF3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=5HGrW9tewqM/OGJ44gYhq2AZZQFG+6r0YZMc3bfDIjc=; b=Oe6z+2aKlqbTYB1cwRQHljM6paw+YCzq4wuyDfPRL0LQ4mQpK1Kcu63MIhoxZCIKLd vCta2CHmqBvYLygyqaAW7ahID/XWRG4dWhA+rti7IitAxt1WAne1OpfiM5cQkQGwHCCN 2paLCgcO9oacQ4MFSLD6TQ2NkUVHri4X+LNCZAV3j5uK2dg0X66v7pFBFk2Qs65J1gcy GZC7VIybE2D0CeBecsJzrjWxdM2InPThUVoHXMGE5dTFMrKNlhw1X4aeId29egeARo8G y2JdbDUp4LqGU54RRmaDnladIjf4M1F/PZfFTSUGLekZtlCMQrIgbijnIXUqtdvjHHsp gjZA==
MIME-Version: 1.0
X-Received: by 10.180.101.170 with SMTP id fh10mr6490088wib.22.1374860880235;  Fri, 26 Jul 2013 10:48:00 -0700 (PDT)
From: gvithal 
Date: Fri, 26 Jul 2013 10:48:00 -0700
Message-ID: <-1990358364323232564@unknownmsgid>
To: "sthaug@nethelp.no" , "stenc@s-carlsen.dk" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-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, 26 Jul 2013 17:48:04 -0000

 Respond by August 9, 2013!
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Same here. I have reviewed earlier versions of this document. DHCPv6
failover is definitely required and I am support the WG taking this up.

Sent from my Windows Phone From: sthaug@nethelp.no
Sent: =E2=80=8E7/=E2=80=8E26/=E2=80=8E2013 22:28
To: stenc@s-carlsen.dk
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03
- Respond by August 9, 2013!
> I have not had the time to read the proposal yet, I believe it is useful
> to have failover available for larger installations.
>=20
> So, please don't drop it.

Same thing here. I'm on vacation with rather poor Internet access
(happens to be the U.S., but that's another discussion). I'm very
definitely interested in this draft.

Steinar Haug, AS 2116

>=20
> On 26/07/13 17:42, Tomek Mrugalski wrote:
> > On 19.07.2013 15:59, Bernie Volz (volz) wrote:
> >> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
> >> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
> >> believe it is ready for working group last call. Please review this
> >> draft and indicate whether or not you feel it is ready to be published=
.
> >> Your input is important!
> > I support this work moving forward. It doesn't count much, as I'm co-au=
thor.
> >
> > I'm somewhat disappointed with the complete lack of any comments. When
> > we started the work on v6 failover, there was exactly 20 people
> > expressing their interest in this work that wanted to join the the
> > effort. A year and a half passed and now there seems to be noone to eve=
n
> > say "yeah, it's ok".
> >
> > A week has passed for this WGLC already. WGLC will end in 2 weeks, so
> > there's still plenty of time for a through review. If you want to have
> > v6 failover, respond. Make no mistake - without sufficient support, thi=
s
> > work will fail WGLC.
> >
> > If you have time - please review it. If you are busy or just don't care
> > about the details, saying that you support this work is useful and you
> > want it to move forward is helpful, too.
> >
> > Tomek
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
>=20
> --=20
> Best regards
>=20
> Sten Carlsen
>=20
> No improvements come from shouting:
>=20
>        "MALE BOVINE MANURE!!!"=20
>=20
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

From gvithal@gmail.com  Fri Jul 26 11:12: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 9872E11E8114 for ; Fri, 26 Jul 2013 11:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRl-hqd0494C for ; Fri, 26 Jul 2013 11:12:46 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDC711E8126 for ; Fri, 26 Jul 2013 11:12:44 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id m46so2149453wev.22 for ; Fri, 26 Jul 2013 11:12:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=5HGrW9tewqM/OGJ44gYhq2AZZQFG+6r0YZMc3bfDIjc=; b=uPde5/5Yxz1ALR02wJa8iri5vpih17MglmdatEQEBB2eAKhcti+ZdHnXqUoz8lKfc/ jdGBGUHezth6K4rpbni3l6VJpXgYi0Tac+8QQ47EBe4PO4VbHrSgZ59Kdt/Zj0zRTzWK JO1rpqXKgQuOoXkVrq8FPGH1KH9NzX1SBfHFuuRTxvMD0ylfFmlJEGRGQP0STlFLAZRA vco/EAaOaasMNAhm+1p7uLc7fbtjfXf0mCHjs5oEqVyYx/3oscUduCTJBvK1c3JZxSg/ sD6qTr08AzFQBtLA+78OQb9WuYtvUlfsIheUShDlZ72diwsORpqPYHU2FtZICDpG/5Q8 1LGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=5HGrW9tewqM/OGJ44gYhq2AZZQFG+6r0YZMc3bfDIjc=; b=PgLQ4yJ70Cl4WWam521/ROub4ds5ISPPxzqWbwCTFVaROcAPgABmDptVJ7elbVcUtc IQLVnU42fj2jyWaPKwi+ELzOrAUmjYVchaMpJ+GH1VMHOVCruE4WQ8/NwoY/4vve/AJp aR2B/1g64yc5AnWNOtndvucLQIBEGEDpcqgiO1pzUWVfyaSN7Tb92iAadsilTKn6LUGy T83Ty2P9qdzEultY9Y3WALXhWEqIKCVLC19EGCSicSyuZvPmLV6E8U0cWDY/WvpBoY9F cNsWJtcbFl7HCg1PRdBl9zsh4rKng5pjLUrfuh3jQN+JBTLldhTVFnRogNhjM4IviFA0 ax6A==
MIME-Version: 1.0
X-Received: by 10.180.185.49 with SMTP id ez17mr6541491wic.12.1374862362274; Fri, 26 Jul 2013 11:12:42 -0700 (PDT)
From: gvithal 
Date: Fri, 26 Jul 2013 11:12:42 -0700
Message-ID: <4550687096156572689@unknownmsgid>
To: "sthaug@nethelp.no" , "stenc@s-carlsen.dk" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-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, 26 Jul 2013 18:12:46 -0000

 Respond by August 9, 2013!
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Same here. I have reviewed earlier versions of this document. DHCPv6
failover is definitely required and I am support the WG taking this up.

Sent from my Windows Phone From: sthaug@nethelp.no
Sent: =E2=80=8E7/=E2=80=8E26/=E2=80=8E2013 22:28
To: stenc@s-carlsen.dk
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03
- Respond by August 9, 2013!
> I have not had the time to read the proposal yet, I believe it is useful
> to have failover available for larger installations.
>=20
> So, please don't drop it.

Same thing here. I'm on vacation with rather poor Internet access
(happens to be the U.S., but that's another discussion). I'm very
definitely interested in this draft.

Steinar Haug, AS 2116

>=20
> On 26/07/13 17:42, Tomek Mrugalski wrote:
> > On 19.07.2013 15:59, Bernie Volz (volz) wrote:
> >> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
> >> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
> >> believe it is ready for working group last call. Please review this
> >> draft and indicate whether or not you feel it is ready to be published=
.
> >> Your input is important!
> > I support this work moving forward. It doesn't count much, as I'm co-au=
thor.
> >
> > I'm somewhat disappointed with the complete lack of any comments. When
> > we started the work on v6 failover, there was exactly 20 people
> > expressing their interest in this work that wanted to join the the
> > effort. A year and a half passed and now there seems to be noone to eve=
n
> > say "yeah, it's ok".
> >
> > A week has passed for this WGLC already. WGLC will end in 2 weeks, so
> > there's still plenty of time for a through review. If you want to have
> > v6 failover, respond. Make no mistake - without sufficient support, thi=
s
> > work will fail WGLC.
> >
> > If you have time - please review it. If you are busy or just don't care
> > about the details, saying that you support this work is useful and you
> > want it to move forward is helpful, too.
> >
> > Tomek
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
>=20
> --=20
> Best regards
>=20
> Sten Carlsen
>=20
> No improvements come from shouting:
>=20
>        "MALE BOVINE MANURE!!!"=20
>=20
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

From kkinnear@cisco.com  Fri Jul 26 12:19:06 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 C317811E812B for ; Fri, 26 Jul 2013 12:19:06 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWuZRDy8xSB6 for ; Fri, 26 Jul 2013 12:19:02 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E307511E8115 for ; Fri, 26 Jul 2013 12:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1374866342; x=1376075942; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wDhyJSocje3fZAHbQUwnYUipOf/wz0W2hTqR+/NWWEU=; b=Uh8TbcWe/d+wbA8tNccI7mD96asg2EIIwTk6HgP+D1cqh6Rp5X+vd1id L1V7IZl5GLaQ6VrTDRU0cX+FeaB92EcWngP4EYQ/6EYewMI7A9kRp8hw0 wqISay405mbfVLIyUQ/Cgsc5Nq12wmjMj4g0lmNoMEcxerehufAkSSy9O Y=;
X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="239818926"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2013 19:19:01 +0000
Received: from printer-xerox-test-5735.cisco.com (printer-xerox-test-5735.cisco.com [161.44.65.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6QJJ0Gv004853;  Fri, 26 Jul 2013 19:19:01 GMT
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Kim Kinnear 
In-Reply-To: <51F298FD.3090009@gmail.com>
Date: Fri, 26 Jul 2013 15:19:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> <51F298FD.3090009@gmail.com>
To: "dhcwg@ietf.org WG" 
X-Mailer: Apple Mail (2.1278)
Cc: Kim Kinnear 
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 26 Jul 2013 19:19:06 -0000

I have read this draft, and also support it moving forward.

As it happens, I'm in the same boat at Tomek -- I'm the other
co-author.

Please, read this draft and comment on whether or not you believe
it should move forward or not!

Thanks -- Kim

On Jul 26, 2013, at 11:42 AM, Tomek Mrugalski wrote:

> On 19.07.2013 15:59, Bernie Volz (volz) wrote:
>> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
>> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design)
>> believe it is ready for working group last call. Please review this
>> draft and indicate whether or not you feel it is ready to be =
published.
>> Your input is important!
> I support this work moving forward. It doesn't count much, as I'm =
co-author.
>=20
> I'm somewhat disappointed with the complete lack of any comments. When
> we started the work on v6 failover, there was exactly 20 people
> expressing their interest in this work that wanted to join the the
> effort. A year and a half passed and now there seems to be noone to =
even
> say "yeah, it's ok".
>=20
> A week has passed for this WGLC already. WGLC will end in 2 weeks, so
> there's still plenty of time for a through review. If you want to have
> v6 failover, respond. Make no mistake - without sufficient support, =
this
> work will fail WGLC.
>=20
> If you have time - please review it. If you are busy or just don't =
care
> about the details, saying that you support this work is useful and you
> want it to move forward is helpful, too.
>=20
> Tomek
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


From Ted.Lemon@nominum.com  Fri Jul 26 15:39: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 7984B11E8186 for ; Fri, 26 Jul 2013 15:39:16 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvANCvYz7ubh for ; Fri, 26 Jul 2013 15:39:09 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id BB4E111E8179 for ; Fri, 26 Jul 2013 15:39:09 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUfL6jQo2E670qYgUSyHWgnr+WnNfGx1Y@postini.com; Fri, 26 Jul 2013 15:39:09 PDT
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 0166B168002 for ; Fri, 26 Jul 2013 15:39:09 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 DC56719006B; Fri, 26 Jul 2013 15:39:08 -0700 (PDT) (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; Fri, 26 Jul 2013 15:39:08 -0700
From: Ted Lemon 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
Thread-Index: Ac6Eh+GxcVMnIa4YTCqgEkgg655xbgFyZUWAAA6JaoA=
Date: Fri, 26 Jul 2013 22:39:07 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077522FEE7@mbx-01.win.nominum.com>
References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com> <51F298FD.3090009@gmail.com>
In-Reply-To: <51F298FD.3090009@gmail.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
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 26 Jul 2013 22:39:16 -0000

On Jul 26, 2013, at 5:42 PM, Tomek Mrugalski  w=
rote:
> A week has passed for this WGLC already. WGLC will end in 2 weeks, so
> there's still plenty of time for a through review. If you want to have
> v6 failover, respond. Make no mistake - without sufficient support, this
> work will fail WGLC.

Last call right before IETF.   Need I say more?   :}   I won't have time to=
 review before the last call expires, because I'm on vacation the week afte=
r the meeting.


From tomasz.mrugalski@gmail.com  Sat Jul 27 09:04:03 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 E5CA321F9A72 for ; Sat, 27 Jul 2013 09:04:03 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4USg7CI2xeDa for ; Sat, 27 Jul 2013 09:04:03 -0700 (PDT)
Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55021F9130 for ; Sat, 27 Jul 2013 09:04:02 -0700 (PDT)
Received: by mail-ee0-f47.google.com with SMTP id e49so2062384eek.6 for ; Sat, 27 Jul 2013 09:04:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=J7FQuIvbMP8aqlXaRS4WfkfImEXnuo0k974QoCUOjiQ=; b=r059Rq+CmYTHYW9jNSBXi6ZNLr6Kqy6ztCitSXnJlUJThKNeVerjV+foRjMnnD9c3y 818WTQjNHa1SRwXa363kf3/s9ygRjSx0b7iwshhpvPTL0uK/zXEAvMoIjXo6s7WxRwTh yrOGXaKl/7Yu+yAJzGLSiBnCmRLVNCtDNIhXMnsHLt2cgp+IzAY+Khp2b4GKWul1ZjTV T8BpwPtMUeDp0G3/i8cH37eh8Bv3ceU7zE8fwvuiFNs/AOmRuxbHowYmztid/W5CyKwZ t5tY+D0mIZydvG8e+EaDyIwOGqA4He1DuRnBlWikOkgAZ9HBubD6oS26wezCissPv4dL YPdA==
X-Received: by 10.14.100.135 with SMTP id z7mr52059400eef.113.1374941041612; Sat, 27 Jul 2013 09:04:01 -0700 (PDT)
Received: from thomson-osx.local ([46.189.28.53]) by mx.google.com with ESMTPSA id e44sm88734953eeh.11.2013.07.27.09.04.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 09:04:00 -0700 (PDT)
Message-ID: <51F3EF6F.1080501@gmail.com>
Date: Sat, 27 Jul 2013 18:03:59 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: DHC WG 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Comments on draft-wing-dhc-dns-reconfigure-01
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: Sat, 27 Jul 2013 16:04:04 -0000

I had some time to review draft-wing-dhc-dns-reconfigure-01. This is a
reasonable draft and I believe it tries to solve a real problem. If
authors are going to request adoption in DHC, we'll need to either
update our charter to include it or get AD permission to adopt it.
Since we're in the process of updating our charter, it will be quite
easy to add that draft to our charter.

Please note the the new charter says that if a new proposal defines
simple option that follows standard behavior, it should be adopted in
the respective WG, not in DHC. That draft defines a simple option, but
it does introduce behavior change, hence it should be adopted in DHC in
my opinion.

However, I have some comments:

Section 3, bullets 2 and 3 mention "regular DNS server", but the
terminology section defines only "DNS server".

Section 3, bullet 3: "regualr" => "regular"

Section 4: Please remove the formatting lines after info-flags. The
format as it is presented now suggested 3 octets of padding. This is
probably not what you want.

Option-length field should be defined explicitly as 1.

Although you only define values 0x01 and 0x02, you should add a text
that the server MUST ignore the option if it doesn't recognize
configured flag.

Also, naming of the field a 'flag' is not fortunate. This is more of an
enumaration value. Flag somewhat implies that this is a bit field and
some people may get idea to set both flags and send 0x03. Obviously that
combination does not make sense.

Section 5 should start with "DHCPv6 relay agents that implement
this functionality MUST support RFC6977."

Section 5, first paragraph "IPV6_HIG_PROI_NORM_SERV": H missing after
HIG.

Section 5 repeats some normative language from RFC6977 using slightly
different wording. It would be better to say that relay sends
RECONFIGURE-REQUEST as defined in RFC6977.

Section 6, first and second bullet: Most of the text about sending
reconfigure is duplicated. It would be easier to read if it had
been written once and apply to both cases.

Section 6 says "The server will remember this configuration for the life
of the lease." That is not sufficient. DHCPv6 clients may have more
than one lease. What about stateless clients? They do
information-request only and there are no leases for them.

It should be specified somewhere (perhaps in section 7) in the text that
only the relay closest to the client is able to do host tracking.
Keep in mind that DHCPv6 allows up to 32 relays. I never heard of
any network that has more than 2 cascade relays, though.

There's also redundancy in the section 6. What if the relay starts
sending reconfigure-request with flag set to 0x01 for a given client?
Server should trigger reconfigure for the first time, but later only
check that the flag matches current configuration and do not trigger
another reconfigure. Sure, such behavior would likely mean bad relay
implementation, but I personally would consider it protocol resiliency.

Section 7 can possibly also mention if the information about clients
is affected by relay reboots, e.g. if the information should be kept
in some form of persistent storage or if the relay should retrieve
its lost information using leasequery. If you do not want to be too
specific, please add an information that specific retention policy is
implementation dependent.

There's one flaw in the whole concept or at least an omission in the way
the mechanism is described. Section 7 mentions information about relay
gathering IPv4/IPv6 - MAC mapping, but the reconfigure-request (and
almost any other operation in DHCPv6) references clients by their
DUIDs. So it should be a triplet of IP/MAC/DUID. Do not assume any
relation between MAC and DUID. There are DUID types that are not based
on MAC. Also, even when the client uses MAC-based DUID, it is perfectly
valid case to use different interface's MAC to generate DUID or keep
using DUID after changing NIC.

Security considerations may also mention that if a relay is compromised,
it may be used to force the uncompromised server to abuse clients by
triggering repetitive reconfigurations. That's not a big issue as in
case of the relay being compromised there are more serious ways intruder
could wreak havoc.

References need updating: I-D.ietf-dhc-triggered-reconfigure
was published as RFC6977.

Section 9: nit-pick: There is no "DHCPv6 Options" section in RFC3315.
It is better to say that IANA is requested to add option-code to the
"DHCP Option Codes" maintained at
www.iana.org/assignments/dhcpv6-parameters (note: the registry that
keeps DHCPv6 options is called "DHCP
option codes", not "DHCPv6 Option codes". It is a bit odd, but that's
how the registry was named).

Section 10.1: Are you sure that all those references are normative?
RFC6052, RFC6147, RFC6384 and RFC6724 seems like informative.

None of the informative references are used in the text. Please either
reference or remove them.

Finally, let me repeat my previous opinion (with my chair hat off): I
consider this draft useful and would like to see it adopted in DHC.

Hope that helps,
Tomek


From praspati@cisco.com  Sun Jul 28 02:01: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 3E2DA21F9D65 for ; Sun, 28 Jul 2013 02:01:48 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XO1zZlxx9Gb for ; Sun, 28 Jul 2013 02:01:43 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB621F9CA8 for ; Sun, 28 Jul 2013 02:01:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6730; q=dns/txt; s=iport; t=1375002103; x=1376211703; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WE9uA5mcwVs0dtvVSY4zZoDypjeC2Yg/8WGAe0z3z8c=; b=IpznXJ6O2UZAlFrJRwnStph/HIrEVhB0LpT/590wiZ1bbRVGmqU3/xVu cv0pGJLKwzXccdxDUgrQMRAPDrWULnlaTJr6DQ7lEagZRQ1M49SAL2FgT fLLy8LSs9ylEdT15xv4z3DYmtCezxRt1lJFNO2QkQNUX5UGw06Bzgwa2S E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFANnc9FGtJV2a/2dsb2JhbABagwY1UL1SgRcWdIImAQQBAQFrBAcSAQgOFAs6BgslAgQOBQgBEIdlAw8MrnQNiF6NFYE/eDEHCoMMbwOIco0Ejg+FJoMUgWlB
X-IronPort-AV: E=Sophos;i="4.89,763,1367971200"; d="scan'208";a="240441654"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2013 09:01:42 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6S91gXw025102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 09:01:42 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.106]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 04:01:42 -0500
From: "Prashanth Patil (praspati)" 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] Comments on draft-wing-dhc-dns-reconfigure-01
Thread-Index: AQHOi3ETwFwM4QCfqkuJwfEc4R4eHA==
Date: Sun, 28 Jul 2013 09:01:41 +0000
Message-ID: 
In-Reply-To: <51F3EF6F.1080501@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.61.92.37]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Comments on draft-wing-dhc-dns-reconfigure-01
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: Sun, 28 Jul 2013 09:01:48 -0000

Hi Tomek,
Thanks for the detailed review. Inline..

On 27/07/13 9:33 PM, "Tomek Mrugalski"  wrote:

>I had some time to review draft-wing-dhc-dns-reconfigure-01. This is a
>reasonable draft and I believe it tries to solve a real problem. If
>authors are going to request adoption in DHC, we'll need to either
>update our charter to include it or get AD permission to adopt it.
>Since we're in the process of updating our charter, it will be quite
>easy to add that draft to our charter.
>
>Please note the the new charter says that if a new proposal defines
>simple option that follows standard behavior, it should be adopted in
>the respective WG, not in DHC. That draft defines a simple option, but
>it does introduce behavior change, hence it should be adopted in DHC in
>my opinion.
>
>However, I have some comments:
>
>Section 3, bullets 2 and 3 mention "regular DNS server", but the
>terminology section defines only "DNS server".
>
>Section 3, bullet 3: "regualr" =3D> "regular"

Accept, will correct.

>
>Section 4: Please remove the formatting lines after info-flags. The
>format as it is presented now suggested 3 octets of padding. This is
>probably not what you want.
>
>Option-length field should be defined explicitly as 1.

Accept.

>
>Although you only define values 0x01 and 0x02, you should add a text
>that the server MUST ignore the option if it doesn't recognize
>configured flag.

Accept.

>
>Also, naming of the field a 'flag' is not fortunate. This is more of an
>enumaration value. Flag somewhat implies that this is a bit field and
>some people may get idea to set both flags and send 0x03. Obviously that
>combination does not make sense.

Agreed. 'Flag' is not appropriate, it is a mutually exclusive enum.

>
>Section 5 should start with "DHCPv6 relay agents that implement
>this functionality MUST support RFC6977."
>
>Section 5, first paragraph "IPV6_HIG_PROI_NORM_SERV": H missing after
>HIG.

In some of the earlier threads, there was discussion on whether info sent
to the server be more generic and not specific to the DNS problem. There
could be other potential actions that a server MAY want to take, either by
built-in design or configuration, based on end point mode i.e IPv4 only,
IPv6 only, Dual-Stack, transitions from Ipv4/6 to Dual-stack and vice
versa. The idea is to now dynamically indicate generic host mode in
RELAY-FORW and RECONFIGURE_REQUEST to the server and the server then
chooses to (RE)CONFIGURE accordingly, the draft defines server behavior
for DNS reconfiguration to start off with.

>
>Section 5 repeats some normative language from RFC6977 using slightly
>different wording. It would be better to say that relay sends
>RECONFIGURE-REQUEST as defined in RFC6977.
>
>Section 6, first and second bullet: Most of the text about sending
>reconfigure is duplicated. It would be easier to read if it had
>been written once and apply to both cases.
>
>Section 6 says "The server will remember this configuration for the life
>of the lease." That is not sufficient. DHCPv6 clients may have more
>than one lease. What about stateless clients? They do
>information-request only and there are no leases for them.

Agreed, stateless clients have to be taken into account.

>
>It should be specified somewhere (perhaps in section 7) in the text that
>only the relay closest to the client is able to do host tracking.
>Keep in mind that DHCPv6 allows up to 32 relays. I never heard of
>any network that has more than 2 cascade relays, though.

Yes, it has to be the one closest to the client. Will specify this.

>
>There's also redundancy in the section 6. What if the relay starts
>sending reconfigure-request with flag set to 0x01 for a given client?
>Server should trigger reconfigure for the first time, but later only
>check that the flag matches current configuration and do not trigger
>another reconfigure. Sure, such behavior would likely mean bad relay
>implementation, but I personally would consider it protocol resiliency.

Right, ideally a relay shouldn=B9t be sending redundant
reconfigure-requests. Needs text to specify behavior on both relay and
server for this.

>
>Section 7 can possibly also mention if the information about clients
>is affected by relay reboots, e.g. if the information should be kept
>in some form of persistent storage or if the relay should retrieve
>its lost information using leasequery. If you do not want to be too
>specific, please add an information that specific retention policy is
>implementation dependent.

Sure.

>
>There's one flaw in the whole concept or at least an omission in the way
>the mechanism is described. Section 7 mentions information about relay
>gathering IPv4/IPv6 - MAC mapping, but the reconfigure-request (and
>almost any other operation in DHCPv6) references clients by their
>DUIDs. So it should be a triplet of IP/MAC/DUID. Do not assume any
>relation between MAC and DUID. There are DUID types that are not based
>on MAC. Also, even when the client uses MAC-based DUID, it is perfectly
>valid case to use different interface's MAC to generate DUID or keep
>using DUID after changing NIC.

Accept.

>
>Security considerations may also mention that if a relay is compromised,
>it may be used to force the uncompromised server to abuse clients by
>triggering repetitive reconfigurations. That's not a big issue as in
>case of the relay being compromised there are more serious ways intruder
>could wreak havoc.

Sure, will mention this risk.

>
>References need updating: I-D.ietf-dhc-triggered-reconfigure
>was published as RFC6977.
>
>Section 9: nit-pick: There is no "DHCPv6 Options" section in RFC3315.
>It is better to say that IANA is requested to add option-code to the
>"DHCP Option Codes" maintained at
>www.iana.org/assignments/dhcpv6-parameters (note: the registry that
>keeps DHCPv6 options is called "DHCP
>option codes", not "DHCPv6 Option codes". It is a bit odd, but that's
>how the registry was named).

Thanks, will do.

>
>Section 10.1: Are you sure that all those references are normative?
>RFC6052, RFC6147, RFC6384 and RFC6724 seems like informative.
>
>None of the informative references are used in the text. Please either
>reference or remove them.

Accept.

>
>Finally, let me repeat my previous opinion (with my chair hat off): I
>consider this draft useful and would like to see it adopted in DHC.
>
>Hope that helps,

Thanks,
Prashanth

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


From msiodelski@gmail.com  Sun Jul 28 15:37: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 2CB8821F9E51 for ; Sun, 28 Jul 2013 15:37:43 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VswGEjSwHm41 for ; Sun, 28 Jul 2013 15:37:42 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id CCFB821F9CFF for ; Sun, 28 Jul 2013 15:37:37 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ep20so3549252lab.9 for ; Sun, 28 Jul 2013 15:37:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=C1fFiwzV5kcuEvVOuxl4e7/cBj1tMWcT3LIMmwtANSU=; b=zzw5ouXYwQsl12O5J7Sd6flIbGGIPauFZMApDg+2ZHtUfmia/xI6R/7+OQ00H9UkGP nn5WifmzXFARhf7tlDe+N1sBVlI2o8uAdksXiOsnTVD1nhsy2pVerrC2DkAi4I4GwqGx HzJ90Ow4rvD/a6fhCD2vau+o02NaSWdSqWZAYLERFZKsiXd2aIfg4oWr2Uvp9azyOW3N C4VvAeMfEineCmchSG+bNO//2eRZ1j47k/HnHa5LVxSUImz/ua/d8ixVK+2S8v0kMH88 4AcJNHfPt1YSG41deRBBmhRCFp5wa/gbGXnYT40yV/0vZFx04iScO48liuxD24g8s26f PipQ==
MIME-Version: 1.0
X-Received: by 10.152.115.146 with SMTP id jo18mr1644344lab.56.1375051056726;  Sun, 28 Jul 2013 15:37:36 -0700 (PDT)
Received: by 10.112.202.170 with HTTP; Sun, 28 Jul 2013 15:37:36 -0700 (PDT)
Date: Mon, 29 Jul 2013 00:37:36 +0200
Message-ID: 
From: Marcin Siodelski 
To: "Qi Sun (sunqi.csnet.thu@gmail.com)" ,  "" , Ted Lemon 
Content-Type: multipart/alternative; boundary=001a11c3561ac8c7f904e29a05d4
Cc: dhcwg@ietf.org
Subject: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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: Sun, 28 Jul 2013 22:37:43 -0000

--001a11c3561ac8c7f904e29a05d4
Content-Type: text/plain; charset=ISO-8859-1

I have read the draft-ietf-dhc-dhcpv6-unknown-msg-01 and I support this
work move forward.

Short comment on this.

It would be good to distinguish between the term "intended recipient" and
"recipient". From the context I understand that the intended recipient is
used with regards to the target for the message being passed through relays
and the recipient is a term used to describe a host which is currently
holding a message. Perhaps this clarification could be placed in the
glossary or somewhere in the text?

Consider this:
"... the message is valid for constructing a new Relay-forward message if
the recipient is a relay agent, the relay agent does not identify itself as
the intended recipient, and the message is not a Relay-Reply message".

There is a mix-up of these two terms which may suggest that the message is
sent to a wrong relay which is  not an "intended recipient", while the
sentence is actually meant to tell that the relay is not a target for the
message being encapsulated.

There is also another sentence:
"A standards-complient DHCP server will never send a message to the a relay
other than in response to a message from a relay, so there should never be
a case where a relay receives a message for which it is the intended
receipient, but is not able to recognize that it is the intended recipient
for the message".

I have to admit that I had to read this sentence 5 times before I caught
the idea what it is about. It should be simplified, perhaps split into
multiple simple sentences. And the last part could be maybe written as:
"...but is not able to recognize it."

Also, the first part may be wrong in a light of rfc3315, section 19.1.1
which says that server may send Reconfigure in the Relay-Reply message and
since it is server initiated message, it is not sent "in response to a
message from relay" as stated in the bullet.

Cheers,
Marcin

--001a11c3561ac8c7f904e29a05d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I have read the draft-ietf-dhc-dhcpv6-unknown-msg-01 and I=
 support this work move forward.

Short comment on =
this.

It would be good to distinguish =
between the term "intended recipient" and "recipient". =
>From the context I understand that the intended recipient is used with rega=
rds to the target for the message being passed through relays and the recip=
ient is a term used to describe a host which is currently holding a message=
. Perhaps this clarification could be placed in the glossary or somewhere i=
n the text?



Consider this:
"... th=
e message is valid for constructing a new Relay-forward message if the reci=
pient is a relay agent, the relay agent does not identify itself as the int=
ended recipient, and the message is not a Relay-Reply message".



There is a mix-up of these two terms which =
may suggest that the message is sent to a wrong relay which is =A0not an &q=
uot;intended recipient", while the sentence is actually meant to tell =
that the relay is not a target for the message being encapsulated.



There is also another sentence:
"A standards-complient DHCP server will never send a message to t=
he a relay other than in response to a message from a relay, so there shoul=
d never be a case where a relay receives a message for which it is the inte=
nded receipient, but is not able to recognize that it is the intended recip=
ient for the message".



I have to admit that I had to read this sen=
tence 5 times before I caught the idea what it is about. It should be simpl=
ified, perhaps split into multiple simple sentences. And the last part coul=
d be maybe written as:


"...but is not able to recognize it."
=

Also, the first part may be wrong in a light of=A0rfc3=
315, section 19.1.1 which says that server may send Reconfigure in the Rela=
y-Reply message and since it is server initiated message, it is not sent &q=
uot;in response to a message from relay" as stated in the bullet.


Cheers,
Marcin


--001a11c3561ac8c7f904e29a05d4--

From Ted.Lemon@nominum.com  Sun Jul 28 15:42:37 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 7F10121F9E9E for ; Sun, 28 Jul 2013 15:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.569
X-Spam-Level: 
X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdkmZ+GI3p7L for ; Sun, 28 Jul 2013 15:42:30 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5721F9E9F for ; Sun, 28 Jul 2013 15:42:30 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUfWeVWkcd5zRnchNc4i/3xtv7ABlHO4R@postini.com; Sun, 28 Jul 2013 15:42:30 PDT
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 650881B8244 for ; Sun, 28 Jul 2013 15:42:29 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 4A1F819006B; Sun, 28 Jul 2013 15:42:29 -0700 (PDT) (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; Sun, 28 Jul 2013 15:42:29 -0700
From: Ted Lemon 
To: Marcin Siodelski 
Thread-Topic: Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
Thread-Index: AQHOi+MQLV3h4mNt20+Shng/eneZrJl7JMiA
Date: Sun, 28 Jul 2013 22:42:28 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>
References: 
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: <9C848F0EA64531478DA70A790F00144C@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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: Sun, 28 Jul 2013 22:42:37 -0000

On Jul 29, 2013, at 12:37 AM, Marcin Siodelski  wrote=
:
> Also, the first part may be wrong in a light of rfc3315, section 19.1.1 w=
hich says that server may send Reconfigure in the Relay-Reply message and s=
ince it is server initiated message, it is not sent "in response to a messa=
ge from relay" as stated in the bullet.

Those messages are never sent to relay agents.

Your other comments sound right to me, and I don't mean to say that the las=
t comment doesn't require clarification, just that this is why the text cur=
rently reads that way.

Thanks for doing the review!


From msiodelski@gmail.com  Mon Jul 29 00:05: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 AC86621F8BE6 for ; Mon, 29 Jul 2013 00:05:18 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW5QDZt2ucWJ for ; Mon, 29 Jul 2013 00:05:18 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A1F9121F87B7 for ; Mon, 29 Jul 2013 00:05:17 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id fp13so3654599lab.38 for ; Mon, 29 Jul 2013 00:05:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VmtWO35M8LP7jbIfkwvpmgaNCn45tPnXKG84TxQI8Mw=; b=CeN74EOp8sl8YSluP109RkkgONyjMaxmPNyrP2q5VhvoBNBNC3NWq6b1ulbtf3jw/D /ZqFYwCtIY8TdaAePxRmKaj45DLPXelADtMyWDbAeQ0ZWKpixjY+qOO7paHoRWleBDue T/1D/5AKs6A4gGFUQf7eGGBp0pQrMequX9WMJkLv85//V8dKwEHTsbhigKCZJjR0AGF3 qSBoxEYXyUNII1A40NAPEegHKSDSxF1pQeXeyznItqLFlC5jYIgNiW1GpdcrM/L23lEP MWvi+4R7HJZSPAVmDetHD073+rNQD4iEx4Z6Q9vBBj9PsL8yUdc+e5aQOimuTEigib/P ERmw==
MIME-Version: 1.0
X-Received: by 10.112.180.164 with SMTP id dp4mr25342815lbc.68.1375081516514;  Mon, 29 Jul 2013 00:05:16 -0700 (PDT)
Received: by 10.112.202.170 with HTTP; Mon, 29 Jul 2013 00:05:16 -0700 (PDT)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>
Date: Mon, 29 Jul 2013 09:05:16 +0200
Message-ID: 
From: Marcin Siodelski 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001a11c2650e5445e404e2a11d4c
Cc: "" , "" 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 07:05:18 -0000

--001a11c2650e5445e404e2a11d4c
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jul 29, 2013 at 12:42 AM, Ted Lemon  wrote:

> On Jul 29, 2013, at 12:37 AM, Marcin Siodelski 
> wrote:
> > Also, the first part may be wrong in a light of rfc3315, section 19.1.1
> which says that server may send Reconfigure in the Relay-Reply message and
> since it is server initiated message, it is not sent "in response to a
> message from relay" as stated in the bullet.
>
> Those messages are never sent to relay agents.
>
> According to RFC3315, server may use Relay-Reply message if it can't send
Reconfigure directly to the client:

"If the server does not have an address to which it can send the
Reconfigure message directly to the client, the server uses a Relay-reply
message (as described in section 20.3) to send the Reconfigure message to a
relay agent that will relay the message to the client."

So, my understanding was that this is the server-initiated message which is
NOT sent in response to relay's message. IMO, this invalidates the first
part of the bullet which says "A standards-complient DHCP server will never
send a message to relay other than in response to a message from a relay.."

Marcin

--001a11c2650e5445e404e2a11d4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Jul 29, 2013 at 12:42 AM, Ted Lemon <Ted.Lemo=
n@nominum.com> wrote:


On Jul 29, 2013, at 12:37 AM, Marcin Sio=
delski <msiodelski@gmail.com=
> wrote:


> Also, the first part may be wrong in a light of rfc3315, section 19.1.=
1 which says that server may send Reconfigure in the Relay-Reply message an=
d since it is server initiated message, it is not sent "in response to=
 a message from relay" as stated in the bullet.





Those messages are never sent to relay agents.


According to RFC3315, server may use Relay-Repl=
y message if it can't send Reconfigure directly to the client:

"If the server does not have an address to which it can send the Reconfigure=
 message directly to the client, the server uses a Relay-reply message (as described in s=
ection 20.3) to send the Reconfigure message to a relay agent that will relay the message=
 to the client=
."



So, my understanding was that this is the server-initiated message whic=
h is NOT sent in response to relay's message. IMO, this invalidates the=
 first part of the bullet which says "A standards-complient DHCP serve=
r will never send a message to relay other than in response to a message fr=
om a relay.."


Marcin


--001a11c2650e5445e404e2a11d4c--

From Ted.Lemon@nominum.com  Mon Jul 29 00:33: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 7C41221F8F4F for ; Mon, 29 Jul 2013 00:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.57
X-Spam-Level: 
X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjqL+H-gmYnm for ; Mon, 29 Jul 2013 00:33:31 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9A67821F8415 for ; Mon, 29 Jul 2013 00:33:28 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUfYaxwEd5Iu5aYh0e0iqhkksGj9Mp7Cg@postini.com; Mon, 29 Jul 2013 00:33:28 PDT
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 F12F01B825D for ; Mon, 29 Jul 2013 00:33:26 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 A74B919006B; Mon, 29 Jul 2013 00:33:25 -0700 (PDT) (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, 29 Jul 2013 00:33:20 -0700
From: Ted Lemon 
To: Marcin Siodelski 
Thread-Topic: Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
Thread-Index: AQHOi+MQLV3h4mNt20+Shng/eneZrJl7JMiAgACMvwCAAAfXAA==
Date: Mon, 29 Jul 2013 07:33:18 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@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="iso-8859-1"
Content-ID: <4A2D311F2E105A4E9FD72EA58C3CD917@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 07:33:38 -0000

On Jul 29, 2013, at 9:05 AM, Marcin Siodelski  wrote:
> According to RFC3315, server may use Relay-Reply message if it can't send=
 Reconfigure directly to the client:

Right.   That's a relay-reply message, not a reconfigure message.



From gnocuil@gmail.com  Mon Jul 29 00:48: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 A9D8121F9956 for ; Mon, 29 Jul 2013 00:48:39 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46n4O+OeoLm2 for ; Mon, 29 Jul 2013 00:48:39 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3DD21F9970 for ; Mon, 29 Jul 2013 00:48:38 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id m15so4619027wgh.29 for ; Mon, 29 Jul 2013 00:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W2pkx2hlD33bQhvntNfJhtM/o76iZCyGxQ6ls/VvYyw=; b=jQNnY8uMS18EFMiuVCJcUwZKJTGG1eitAkojBm0T2Jv8SKiZLk9rwbgdXNTxJ8GBus M7T6LEfI5pFVahppQyv4y2FiSeQPO6fAISFIeLF83UKABec5W90TLxIGxO2ibpKmAekS doSsAqd5dPpbIUbbvoWnUZqvtVaQD/WmlfZ8dvoTRl7IKTe137fCy5f8u9FY8Ox4E4oi h99pk3wSlBtluiXjYRMhic0F4ZpJpPa1ValzCU8UthAui70U/tHdf8TjjTyxCqzYVvop W5CrCou59hTC6OJGFyRir9PRKNRkeQJgXPlmb1dNGAWf2d185OiEfv2EMmQd6HWrgQOa zBWw==
X-Received: by 10.194.2.13 with SMTP id 13mr42860225wjq.74.1375084117384; Mon, 29 Jul 2013 00:48:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.10.67 with HTTP; Mon, 29 Jul 2013 00:48:17 -0700 (PDT)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com>
From: Cong Liu 
Date: Mon, 29 Jul 2013 15:48:17 +0800
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=047d7b3a87565a650a04e2a1b847
Cc: "" , "" 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 07:48:39 -0000

--047d7b3a87565a650a04e2a1b847
Content-Type: text/plain; charset=ISO-8859-1

Hi Ted,

This relay-reply message is not a response to relay's message.

Cong

2013/7/29 Ted Lemon 

> On Jul 29, 2013, at 9:05 AM, Marcin Siodelski 
> wrote:
> > According to RFC3315, server may use Relay-Reply message if it can't
> send Reconfigure directly to the client:
>
> Right.   That's a relay-reply message, not a reconfigure message.
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>

--047d7b3a87565a650a04e2a1b847
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Ted,

This relay-reply message is not a response to re=
lay's message.

Cong

2013/7/29 Ted Lemon <Ted.Lemon@nominum.com>



On Jul 29, 2013, at 9:05 A=
M, Marcin Siodelski <msiodelski@=
gmail.com> wrote:



> According to RFC3315, server may use Relay-Reply message if it can'=
;t send Reconfigure directly to the client:




Right. =A0 That's a relay-reply message, not a reconfigure messag=
e.






_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/dhcwg





--047d7b3a87565a650a04e2a1b847--

From tomasz.mrugalski@gmail.com  Mon Jul 29 00:49:55 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 C806921F9CF1 for ; Mon, 29 Jul 2013 00:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6J6Gsc175I8 for ; Mon, 29 Jul 2013 00:49:54 -0700 (PDT)
Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA0721F9CE8 for ; Mon, 29 Jul 2013 00:49:52 -0700 (PDT)
Received: by mail-pb0-f48.google.com with SMTP id ma3so752873pbc.21 for ; Mon, 29 Jul 2013 00:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=rTBnPLC4aJVWgcpJ7q6wJJJrAQUmv8Wi0nk8pO5YnyU=; b=ueH5wtxJKQzmJ4ayltMNE1C9gzvt3iOWCEjSlb3VeIadZLyBoj3MN9UnsfI4DzJNm3 oQG4mWVXl49QmUv8vFSbttNtralhRP9tr3C06GUe4ahACZMf6xKSLcs15/qSQ++YuocJ igFyxRS2/R0gxO2KglhKQly9U6rb6h7I7d5pB5yOOwdSOBWSuBKpHrPoAMpWWrA6h4vC mObDEgoccqtdDXI3EsvBIeoB4UgIAAmUiwi/5kQUv7fTjUdH/xgMKvDWX9P5C2ebjYfY 6rJ212Kv/buk4Jyf0A33AWgLTFvclzlNI7LKNxv54AZCMwe1AbdalvXAw9wYV1eYQblR THew==
X-Received: by 10.68.217.137 with SMTP id oy9mr66117936pbc.130.1375084191833;  Mon, 29 Jul 2013 00:49:51 -0700 (PDT)
Received: from dhcp-108b.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id nv6sm75458523pbc.6.2013.07.29.00.49.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 00:49:51 -0700 (PDT)
Message-ID: <51F61E9A.4040105@gmail.com>
Date: Mon, 29 Jul 2013 09:49:46 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ted Lemon 
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" , "" 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 07:49:55 -0000

On 13-07-29 09:33, Ted Lemon wrote:
> On Jul 29, 2013, at 9:05 AM, Marcin Siodelski  wrote:
>> According to RFC3315, server may use Relay-Reply message if it can't send Reconfigure directly to the client:
> 
> Right.   That's a relay-reply message, not a reconfigure message.
Yes, but the message type is irrelevant. Marcin's point was that
the draft says that that server will never send a message that is not a
response to a message from a relay, which is not true.

Note that the draft says nothing about message types. Here's part of the
text that needs to be updated in my opinion: "A standards-compliant DHCP
server will never send a message to the a relay other than in response
to a message from a relay,...".


From Ted.Lemon@nominum.com  Mon Jul 29 00:53:01 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 9C7E821F99BA for ; Mon, 29 Jul 2013 00:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level: 
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS-40jd-C6HQ for ; Mon, 29 Jul 2013 00:52:55 -0700 (PDT)
Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3521F21F9D11 for ; Mon, 29 Jul 2013 00:52:54 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUfYfVSGPAf2hTfoV5mgU6LrAhwkBoDQj@postini.com; Mon, 29 Jul 2013 00:52:54 PDT
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 AD63C1B825D for ; Mon, 29 Jul 2013 00:52:53 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 A46F719006B; Mon, 29 Jul 2013 00:52:53 -0700 (PDT) (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, 29 Jul 2013 00:52:53 -0700
From: Ted Lemon 
To: Tomek Mrugalski 
Thread-Topic: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
Thread-Index: AQHOi+MQLV3h4mNt20+Shng/eneZrJl7JMiAgACMvwCAAAfXAIAABJcAgAAA34A=
Date: Mon, 29 Jul 2013 07:52:52 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630775233A9F@mbx-01.win.nominum.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com> <51F61E9A.4040105@gmail.com>
In-Reply-To: <51F61E9A.4040105@gmail.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: <3600342791CE7648A90B652DAF008A82@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 07:53:01 -0000

On Jul 29, 2013, at 9:49 AM, Tomek Mrugalski  w=
rote:
> On 13-07-29 09:33, Ted Lemon wrote:
>> On Jul 29, 2013, at 9:05 AM, Marcin Siodelski  wro=
te:
>>> According to RFC3315, server may use Relay-Reply message if it can't se=
nd Reconfigure directly to the client:
>>=20
>> Right.   That's a relay-reply message, not a reconfigure message.
> Yes, but the message type is irrelevant. Marcin's point was that
> the draft says that that server will never send a message that is not a
> response to a message from a relay, which is not true.
>=20
> Note that the draft says nothing about message types. Here's part of the
> text that needs to be updated in my opinion: "A standards-compliant DHCP
> server will never send a message to the a relay other than in response
> to a message from a relay,...".

What I am getting at is that that text is referring to messages whose final=
 destination is the relay.   Relay-replies are *to* the relay, but that is =
not the final destination of the communication, and the relay doesn't have =
to do anything special with them=97it just unwraps the enclosed message and=
 forwards it to the specified address.



From sunqi.csnet.thu@gmail.com  Mon Jul 29 01:04:29 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 0948821F9AF0 for ; Mon, 29 Jul 2013 01:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tmff4hamyDgd for ; Mon, 29 Jul 2013 01:04:28 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 14FA621F9B0E for ; Mon, 29 Jul 2013 01:04:12 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up15so3675390pbc.26 for ; Mon, 29 Jul 2013 01:04:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Xl2YMLImOBVkbA+63vPSg5NYYipO6lYQITr/6j2kk74=; b=opWVPI8ZUy8IEiPi9uL0W1a3qvTOnMGMkqihN/M8+7+00A5BUxFeDWG4wSenmOpD0l gIWxQ+8i79W0hs0j5HURMo3OMtsw+yVokNXkazgw2T4FsJ+jUYhMv/gv4M2UHE5tq7i/ +Clc+chrMPhCOmuQjunSbuhBtztGtdGKtnoN28xBr4ipOyYMIP3jy6AzmK0sHPU/31uw MLbdR9zJP45XClIRBXt0CuGUZDQIDLZH6xS1DWerC0Yc1d2rhljql4BhANJdhvxXorHL pbQVCoJ5VJ4b81yol0W5mXjPMprahjTqaP4O3FAJUTMNDfkqkP6qWARYiWWXKuY40aDs FUBw==
X-Received: by 10.68.252.137 with SMTP id zs9mr66098273pbc.60.1375085050636; Mon, 29 Jul 2013 01:04:10 -0700 (PDT)
Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id pu5sm10301745pac.21.2013.07.29.01.04.08 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:04:09 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=utf-8
From: Qi Sun 
In-Reply-To: <51F61E9A.4040105@gmail.com>
Date: Mon, 29 Jul 2013 10:04:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CBE1E84-BAF6-4447-89D7-A9AA1B371F74@gmail.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com> <51F61E9A.4040105@gmail.com>
To: Tomek Mrugalski 
X-Mailer: Apple Mail (2.1084)
Cc: "" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 08:04:29 -0000

Hi Tomek ,

> Yes, but the message type is irrelevant. Marcin's point was that
> the draft says that that server will never send a message that is not =
a
> response to a message from a relay, which is not true.

What the server sends out is a Relay-Reply message, rather than a =
Reconfigure message. The Relay-reply message is the message that in =
response to the relay agent.


Best Regards,
Qi


On 2013-7-29, at =E4=B8=8A=E5=8D=889:49, Tomek Mrugalski wrote:

> On 13-07-29 09:33, Ted Lemon wrote:
>> On Jul 29, 2013, at 9:05 AM, Marcin Siodelski  =
wrote:
>>> According to RFC3315, server may use Relay-Reply message if it can't =
send Reconfigure directly to the client:
>>=20
>> Right.   That's a relay-reply message, not a reconfigure message.
> Yes, but the message type is irrelevant. Marcin's point was that
> the draft says that that server will never send a message that is not =
a
> response to a message from a relay, which is not true.
>=20
> Note that the draft says nothing about message types. Here's part of =
the
> text that needs to be updated in my opinion: "A standards-compliant =
DHCP
> server will never send a message to the a relay other than in response
> to a message from a relay,...".
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


From sunqi.csnet.thu@gmail.com  Mon Jul 29 01:07:44 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 17BE621F9E79 for ; Mon, 29 Jul 2013 01:07:44 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCFjpyURREKN for ; Mon, 29 Jul 2013 01:07:43 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 757BA21F9E12 for ; Mon, 29 Jul 2013 01:06:40 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up15so3697168pbc.12 for ; Mon, 29 Jul 2013 01:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=sBulFJOZ3XI9gpVPYavNgCeF6rQXUV4sg6xfZ4OyNAA=; b=cTB2xQsC+YoToHlx8+BO6dFS2axOSiD/Sk4+YsE6zv82HncCkbtc7N8I/HNn+u1MOA sqKLGI5zX8reVA/QSF9KuIQdEgdmtN1ALVbo44S3XCmlTID+XrHRG8bhIt/WFeGp3dhS k+cjOOmoNzn7/PEhiNKKf81UzPfP3wPhMi54I0w1AQa5eGvRZHR7KLR/RX5SZ5hwFGiS hn3D4FDggE5Cl7hij9AS5ueGl2atbcvXEIN/CaMzR8JEn9/IwsQKzyVXtAT+8YWPPveA CyG5ZurhOUlMy35IX2UljQgdQtz2oi4tDRTS95/JS6ijfZUZNB0ZAI6/fd3Asb/6rSBA nOwQ==
X-Received: by 10.69.17.1 with SMTP id ga1mr65623849pbd.38.1375085200271; Mon, 29 Jul 2013 01:06:40 -0700 (PDT)
Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id jf4sm75504490pbb.19.2013.07.29.01.06.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:06:39 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-107--506480516
From: Qi Sun 
In-Reply-To: 
Date: Mon, 29 Jul 2013 10:06:34 +0200
Message-Id: 
References: 
To: Marcin Siodelski 
X-Mailer: Apple Mail (2.1084)
Cc: dhcwg@ietf.org, "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 08:07:44 -0000

--Apple-Mail-107--506480516
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


Hi Marcin ,

Thanks for the review!=20

> It would be good to distinguish between the term "intended recipient" =
and "recipient". =46rom the context I understand that the intended =
recipient is used with regards to the target for the message being =
passed through relays and the recipient is a term used to describe a =
host which is currently holding a message. Perhaps this clarification =
could be placed in the glossary or somewhere in the text?
>=20
> Consider this:
> "... the message is valid for constructing a new Relay-forward message =
if the recipient is a relay agent, the relay agent does not identify =
itself as the intended recipient, and the message is not a Relay-Reply =
message".
>=20
> There is a mix-up of these two terms which may suggest that the =
message is sent to a wrong relay which is  not an "intended recipient", =
while the sentence is actually meant to tell that the relay is not a =
target for the message being encapsulated.

How about the following text:

"... the message is valid for constructing a new Relay-forward message =
if a relay agent receives the message, but the relay agent does not =
identify itself as the target of the message, and the message is not a =
Relay-Reply message."

Is the usage of 'target' here is precise?=20

Best Regards,
Qi


--Apple-Mail-107--506480516
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hi Marcin =
,

Thanks for the =
review! 

It would be good to =
distinguish between the term "intended recipient" and "recipient". =46rom =
the context I understand that the intended recipient is used with =
regards to the target for the message being passed through relays and =
the recipient is a term used to describe a host which is currently =
holding a message. Perhaps this clarification could be placed in the =
glossary or somewhere in the text?



Consider this:
"... the message is valid for constructing a new =
Relay-forward message if the recipient is a relay agent, the relay agent =
does not identify itself as the intended recipient, and the message is =
not a Relay-Reply message".



There is a mix-up of these two =
terms which may suggest that the message is sent to a wrong relay which =
is  not an "intended recipient", while the sentence is actually =
meant to tell that the relay is not a target for the message being =
encapsulated.

How about the =
following text:

"... the message is =
valid for constructing a new Relay-forward message if a relay agent =
receives the message, but the relay agent does not =
identify itself as the target of the message, and the message =
is not a Relay-Reply message."

Is the =
usage of 'target' here is precise? 

Best =
Regards,
Qi

=

--Apple-Mail-107--506480516--

From draghuva@cisco.com  Mon Jul 29 00:58: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 1588721F996F for ; Mon, 29 Jul 2013 00:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnlqaRv6gbQi for ; Mon, 29 Jul 2013 00:58:15 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4C021F99FA for ; Mon, 29 Jul 2013 00:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12002; q=dns/txt; s=iport; t=1375084695; x=1376294295; h=from:to:subject:date:message-id:mime-version; bh=KyVwBNxegNRJV6Ejb2PUXA4o19UkLYd7ZdskF/ELfjA=; b=Mtfk3OlrhlVUdEdNyIZkGczRajdixyVTmX9x3IRYXjC1rjJxPfuf9qCF 24fxiqs496NGNdZlJm20OsjiAKMYLgaBo00Xur8SxQ0OOaJABNUmZMAQD KKwcOQ5gsOnaVPU+tCuEVFM1N1I+C9vsi1lbgw2FbjE6T9DS0/g38m90N w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkFAGgf9lGtJXG//2dsb2JhbABRCoJCRDVQtRyIOoEUFnSCJAEBAQQBAQEqQR0BCBEDAQILHS4LFAkJAQQTCIgIDJdToAWORIEIIA0KgxlvA5kIkCOBW4E5gio
X-IronPort-AV: E=Sophos;i="4.89,767,1367971200";  d="scan'208,217";a="240683239"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2013 07:58:14 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6T7wEjE002027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 07:58:14 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.27]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 02:58:14 -0500
From: "Dushyant Raghuvanshi (draghuva)" 
To: "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
Thread-Index: Ac6MMUqkqXzV1NEaRPGFhCskW/1XcA==
Date: Mon, 29 Jul 2013 07:58:13 +0000
Message-ID: <0A2ED610A80E7B4DBCC8E63B8E7EE43027038F0F@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.42.159]
Content-Type: multipart/alternative; boundary="_000_0A2ED610A80E7B4DBCC8E63B8E7EE43027038F0Fxmbrcdx02ciscoc_"
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 29 Jul 2013 01:16:10 -0700
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 29 Jul 2013 07:58:20 -0000

--_000_0A2ED610A80E7B4DBCC8E63B8E7EE43027038F0Fxmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

                I have read this draft and have couple of comments for spel=
ling mistakes to be fixed.
                Below mentioned are the points. With these changes, I think=
 this draft should move forward.

1. Need to change "idenpendent" to "independent" in second paragraph in sec=
tion 6.3.
2. Change "lease" to "least" in "BNDACK MUST contain at lease minimum set o=
f information required to unabiguously identify BNDUDP." in section 8.10.

Thanks & Regards,
Dushyant.


From: "Bernie Volz (volz)" >
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respon=
d by August 9, 2013!
Date: July 19, 2013 9:59:20 AM EDT
To: "dhcwg@ietf.org" >

Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03 (http://tool=
s.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design) believe it is ready =
for working group last call. Please review this draft and indicate whether =
or not you feel it is ready to be published. Your input is important!

This document is the 2nd series of documents related to DHCPv6 failover - t=
he first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requi=
rements which is currently being reviewed by the IESG for publication appro=
val.

At the time of this writing, there is no IPR reported against this draft.

As Tomek is a co-author, I will primarily evaluate consensus after 2013-08-=
09 (August 9th). This is a 3 week last call because of the Berlin IETF meet=
ing and also because of summer-time vacations (at least for those of us in =
the northern hemisphere).

Thanks,

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


--_000_0A2ED610A80E7B4DBCC8E63B8E7EE43027038F0Fxmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


      &nb=
sp;         I have read this draft =
and have couple of comments for spelling mistakes to be fixed.


      &nb=
sp;         Below mentioned are the=
 points. With these changes, I think this draft should move forward.



 


1. Need to c=
hange "idenpendent" to "independent" in second paragrap=
h in section 6.3.


2. Change &q=
uot;lease" to "least" in "BNDACK MUST contain at lease =
minimum set of information required to unabiguously identify BNDUDP." =
in section 8.10.


 


Thanks & Regards,=



Dushyant.


 






 




From:
"Bernie Volz (volz)" <volz@cisco.com>






Subject: [dhcwg] WGLC for draft-ie=
tf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!






Date:
July 19, 2013 9:59:20 AM EDT




 






Folks, the authors of draft-ietf-dhc-dh=
cpv6-failover-design-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6=
-failover-design)
 believe it is ready for working group last call. Please review this draft =
and indicate whether or not you feel it is ready to be published. Your inpu=
t is important!






 






This document is the 2nd series of documents related =
to DHCPv6 failover – the first is http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-fai=
lover-requirements wh=
ich
 is currently being reviewed by the IESG for publication approval.






 






At the time of this writing, there is n=
o IPR reported against this draft.






 






As Tomek is a co-author, I will primari=
ly evaluate consensus after 2013-08-09 (August 9th). This is a 3=
 week last call because of the Berlin IETF meeting and also
 because of summer-time vacations (at least for those of us in the northern=
 hemisphere).






 






Thanks,






 






-       &nb=
sp;  Bernie




_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.ietf.or=
g/mailman/listinfo/dhcwg






 








--_000_0A2ED610A80E7B4DBCC8E63B8E7EE43027038F0Fxmbrcdx02ciscoc_--

From volz@cisco.com  Mon Jul 29 01:33:04 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 B2A0A21F8235 for ; Mon, 29 Jul 2013 01:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X9PtKYoOFtP for ; Mon, 29 Jul 2013 01:32:59 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F096E21F91C4 for ; Mon, 29 Jul 2013 01:32:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8581; q=dns/txt; s=iport; t=1375086769; x=1376296369; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uyeaOO+nytf6HKiiZ2lPg7TUsq/o22agj6bSF2Y9QkU=; b=I7iBEQkqeHbK63rHNVP7NlC+5BHsI0OQ46Ke+d4DsWs+S7tS5q0xfxxa S2asgGZ8pFeeiGtZztyv0FTtAMWqXBAoahUqYl/yrQJCUgezw6nxuB4eE OMRV57lLmKx+IzPw7jkYn6pSQirmv/mSjoj5oKi/+iSL79SUXjt1AMqfA I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAJwn9lGtJV2b/2dsb2JhbABRCoMGNb4mgRUWdIIlAQEEAQEBawsQAgEIPwchBgsUEQIEDgWHfgMPDK5eDYhaBI0VgS+BNQQHgxhvA5V2gWmMJoUmgxQ
X-IronPort-AV: E=Sophos;i="4.89,767,1367971200";  d="scan'208,217";a="240672822"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2013 08:32:47 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6T8WlH4030527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 08:32:47 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 03:32:47 -0500
From: "Bernie Volz (volz)" 
To: Qi Sun 
Thread-Topic: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
Thread-Index: AQHOjDK/JgmgSAgKNUWrOdEwglGNqpl7VAGT
Date: Mon, 29 Jul 2013 08:32:46 +0000
Message-ID: <59AC99E8-885D-4D18-9C4A-3AE649F9FA95@cisco.com>
References: , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_59AC99E8885D4D189C4A3AE649F9FA95ciscocom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding	draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 08:33:04 -0000

--_000_59AC99E8885D4D189C4A3AE649F9FA95ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I wonder if reworking the draft a bit would be worthwhile. In some cases it=
 makes statements that could be dangerous in the long run.

The basic concept is that a received msg is either forwarded or consumed by=
 relay.

If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how to han=
dle it.

If not one of these and not one to be consumed by relay (ie, Reconfigure-Re=
ply), it should be forwarded (Relay-forw) unless policy disallows (ie, not =
client facing interface).

- Bernie (from iPhone)

On Jul 29, 2013, at 10:08 AM, "Qi Sun" > wrote:


Hi Marcin ,

Thanks for the review!

It would be good to distinguish between the term "intended recipient" and "=
recipient". From the context I understand that the intended recipient is us=
ed with regards to the target for the message being passed through relays a=
nd the recipient is a term used to describe a host which is currently holdi=
ng a message. Perhaps this clarification could be placed in the glossary or=
 somewhere in the text?

Consider this:
"... the message is valid for constructing a new Relay-forward message if t=
he recipient is a relay agent, the relay agent does not identify itself as =
the intended recipient, and the message is not a Relay-Reply message".

There is a mix-up of these two terms which may suggest that the message is =
sent to a wrong relay which is  not an "intended recipient", while the sent=
ence is actually meant to tell that the relay is not a target for the messa=
ge being encapsulated.

How about the following text:

"... the message is valid for constructing a new Relay-forward message if a=
 relay agent receives the message, but the relay agent does not identify it=
self as the target of the message, and the message is not a Relay-Reply mes=
sage."

Is the usage of 'target' here is precise?

Best Regards,
Qi

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

--_000_59AC99E8885D4D189C4A3AE649F9FA95ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







I wonder if reworking the draft a bit would be worthwhile. In some cas=
es it makes statements that could be dangerous in the long run. 







The basic concept is that a received msg is either forwarded or consum=
ed by relay.







If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how t=
o handle it.







If not one of these and not one to be consumed by relay (ie, Reconfigu=
re-Reply), it should be forwarded (Relay-forw) unless policy disallows (ie,=
 not client facing interface).



- Bernie (from iPhone)




On Jul 29, 2013, at 10:08 AM, "Qi Sun" <sunqi.csnet.thu@gmail.com> wrote:





















Hi Marcin ,







Thanks for the review! 





















It would be good to distinguish between the term "inte=
nded recipient" and "recipient". From the context I understa=
nd that the intended recipient is used with regards to the target for the m=
essage being passed through relays and the recipient is
 a term used to describe a host which is currently holding a message. Perha=
ps this clarification could be placed in the glossary or somewhere in the t=
ext?







Consider this:


"... the message is valid for constructing a new Relay=
-forward message if the recipient is a relay agent, the relay agent does no=
t identify itself as the intended recipient, and the message is not a Relay=
-Reply message".







There is a mix-up of these two terms which may suggest that=
 the message is sent to a wrong relay which is  not an "intended =
recipient", while the sentence is actually meant to tell that the rela=
y is not a target for the message being encapsulated.











How about the following text:







"... the message is valid for constructing a new Relay-forward message=
 if a relay agent receives the message, but the relay agent
 does not identify itself as the target of the message, and the message is=
 not a Relay-Reply message."







Is the usage of 'target' here is precise? 







Best Regards,


Qi












_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg








--_000_59AC99E8885D4D189C4A3AE649F9FA95ciscocom_--

From sunqi.csnet.thu@gmail.com  Mon Jul 29 02:03:14 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 1102211E80D1 for ; Mon, 29 Jul 2013 02:03:14 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+iMCii1C+md for ; Mon, 29 Jul 2013 02:03:11 -0700 (PDT)
Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDC211E80A2 for ; Mon, 29 Jul 2013 02:03:11 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id rq2so679999pbb.19 for ; Mon, 29 Jul 2013 02:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=RbnDQWyitD3okLoEfiYDsAVe3M/Lgpc4LKKBAIo4dQA=; b=zNwmUlXXagIJ0ZQ4p5sV9LAlBWQmvij/2EYA8beBZ0TaY3ScZcayhwLXvH2QHFC1N5 kjEcmEwFgWsznnkNMrHFyvLpHj2POLsqmIw+9Au4vF7D6kyqyACu94yVyUXxSklS7FL3 rpN2toU+ci8XdtNPi/RfjWVTG7YfVXIgvcp23kyAAO22TQUY+QTxKkBw6dwP+asxfGvN HE1Xh/nF1k3utehFPQR+JtoyXVe6Ii5b/JKTAij3SDBrIkIDt1CQY4hnjc3E1TXbtra1 xz+0+ddof8uPgPb6CNhV1o7TztmbGTJfNPm/4HSc5NAOXUxRkaaf5qMnRDhJZbGaQBZR thKA==
X-Received: by 10.68.162.36 with SMTP id xx4mr21795781pbb.47.1375088590980; Mon, 29 Jul 2013 02:03:10 -0700 (PDT)
Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id ue9sm19628161pab.7.2013.07.29.02.03.08 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 02:03:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-110--503093091
From: Qi Sun 
In-Reply-To: <59AC99E8-885D-4D18-9C4A-3AE649F9FA95@cisco.com>
Date: Mon, 29 Jul 2013 11:03:01 +0200
Message-Id: <9EF31D11-CBF7-41FD-BB64-71D69FB015C1@gmail.com>
References: ,  <59AC99E8-885D-4D18-9C4A-3AE649F9FA95@cisco.com>
To: "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1084)
Cc: "dhcwg@ietf.org" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 09:03:14 -0000

--Apple-Mail-110--503093091
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Bernie,

> I wonder if reworking the draft a bit would be worthwhile. In some =
cases it makes statements that could be dangerous in the long run.=20

Would you please elaborate so that we could work on them?


Best Regards,
Qi Sun


On 2013-7-29, at =E4=B8=8A=E5=8D=8810:32, Bernie Volz (volz) wrote:

> I wonder if reworking the draft a bit would be worthwhile. In some =
cases it makes statements that could be dangerous in the long run.=20
>=20
> The basic concept is that a received msg is either forwarded or =
consumed by relay.
>=20
> If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how =
to handle it.
>=20
> If not one of these and not one to be consumed by relay (ie, =
Reconfigure-Reply), it should be forwarded (Relay-forw) unless policy =
disallows (ie, not client facing interface).
>=20
> - Bernie (from iPhone)
>=20
> On Jul 29, 2013, at 10:08 AM, "Qi Sun"  =
wrote:
>=20
>>=20
>> Hi Marcin ,
>>=20
>> Thanks for the review!=20
>>=20
>>> It would be good to distinguish between the term "intended =
recipient" and "recipient". =46rom the context I understand that the =
intended recipient is used with regards to the target for the message =
being passed through relays and the recipient is a term used to describe =
a host which is currently holding a message. Perhaps this clarification =
could be placed in the glossary or somewhere in the text?
>>>=20
>>> Consider this:
>>> "... the message is valid for constructing a new Relay-forward =
message if the recipient is a relay agent, the relay agent does not =
identify itself as the intended recipient, and the message is not a =
Relay-Reply message".
>>>=20
>>> There is a mix-up of these two terms which may suggest that the =
message is sent to a wrong relay which is  not an "intended recipient", =
while the sentence is actually meant to tell that the relay is not a =
target for the message being encapsulated.
>>=20
>> How about the following text:
>>=20
>> "... the message is valid for constructing a new Relay-forward =
message if a relay agent receives the message, but the relay agent does =
not identify itself as the target of the message, and the message is not =
a Relay-Reply message."
>>=20
>> Is the usage of 'target' here is precise?=20
>>=20
>> Best Regards,
>> Qi
>>=20
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg


--Apple-Mail-110--503093091
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I wonder if reworking the draft a bit would be =
worthwhile. In some cases it makes statements that could be dangerous in =
the long run. 

Would you =
please elaborate so that we could work on them?




I wonder if reworking the draft a bit would be worthwhile. In some =
cases it makes statements that could be dangerous in the long =
run. 







The basic concept is that a received msg is either forwarded or =
consumed by relay.







If the message is a Relay-forw or Relay-Reply, RFC 3315 explains =
how to handle it.







If not one of these and not one to be consumed by relay (ie, =
Reconfigure-Reply), it should be forwarded (Relay-forw) unless policy =
disallows (ie, not client facing interface).



- Bernie (from iPhone)




On Jul 29, 2013, at 10:08 AM, "Qi Sun" <sunqi.csnet.thu@gmail.com>=
; wrote:





















Hi Marcin ,







Thanks for the review! 





















It would be good to distinguish between the term =
"intended recipient" and "recipient". =46rom the context I understand =
that the intended recipient is used with regards to the target for the =
message being passed through relays and the recipient is
 a term used to describe a host which is currently holding a message. =
Perhaps this clarification could be placed in the glossary or somewhere =
in the text?







Consider this:


"... the message is valid for constructing a new =
Relay-forward message if the recipient is a relay agent, the relay agent =
does not identify itself as the intended recipient, and the message is =
not a Relay-Reply message".







There is a mix-up of these two terms which may suggest =
that the message is sent to a wrong relay which is  not an =
"intended recipient", while the sentence is actually meant to tell that =
the relay is not a target for the message being encapsulated.











How about the following text:







"... the message is valid for constructing a new Relay-forward =
message if a relay agent receives the message, but the =
relay agent
 does not identify itself as the target of the message, and =
the






Is the usage of 'target' here is precise? 







Best Regards,


Qi












_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.ietf.org/=
mailman/listinfo/dhcwg










=

--Apple-Mail-110--503093091--

From sunqi.csnet.thu@gmail.com  Mon Jul 29 02:06: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 55FCA21F9D68 for ; Mon, 29 Jul 2013 02:06:27 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LR0tduiJe0j for ; Mon, 29 Jul 2013 02:06:24 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id F209021F9FEA for ; Mon, 29 Jul 2013 02:06:12 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id r11so942552pdi.13 for ; Mon, 29 Jul 2013 02:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=WKRLyooiCK6wA7zK0Lz32QM0cRpnr2OvdEIY/+L0g7A=; b=HKoGr7q4rvaygFltrYl3kn+lVu5OzJf/UhEFJe/1thVMcT7wjrSCCbVa2FBSWYnLe+ oxb0K5O4NmyFfDziDrZxu7Z5XfvNcr5ZPz0t+oeb123CedvNCBD5MVXplOCoJpjMDrzs dX41vxzQ5s8dFMK316iM8o82wMmLVS7FeLIiYvIxeGj+Ll3t8Uz0cx6WSMvkMNEYBe/M LO9B2M6LYIGVQtdmztkFR7d9gyQfBbnOx3/VvL0hh2m8FewgcpizIQshe7Mqih2tT0DU L19h0UHUUD+pFaNjG4eSx6PrBLqvhNHjgBLLZAKR+CZJMnuUo2JG7ncLAHAvcscYKm7B o36w==
X-Received: by 10.66.136.237 with SMTP id qd13mr68553374pab.74.1375088772461;  Mon, 29 Jul 2013 02:06:12 -0700 (PDT)
Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id w8sm19652522paj.4.2013.07.29.02.06.09 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 02:06:11 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-111--502907211
From: Qi Sun 
In-Reply-To: <51F61E9A.4040105@gmail.com>
Date: Mon, 29 Jul 2013 11:06:07 +0200
Message-Id: <83CD75ED-5232-418C-A5F6-0A3F62684839@gmail.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com> <51F61E9A.4040105@gmail.com>
To: Tomek Mrugalski 
X-Mailer: Apple Mail (2.1084)
Cc: "" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 09:06:28 -0000

--Apple-Mail-111--502907211
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


Tomek ,

> Note that the draft says nothing about message types. Here's part of =
the
> text that needs to be updated in my opinion: "A standards-compliant =
DHCP
> server will never send a message to the a relay other than in response
> to a message from a relay,...".

What do you think of the text:
NEW:
"A standards-complient DHCP server will never send a message to a relay =
for which the relay is the the intended recipient,  but is not able to =
recognize it."

Would it resolve the confusion?

Thanks,
Qi


On 2013-7-29, at =E4=B8=8A=E5=8D=889:49, Tomek Mrugalski wrote:

> On 13-07-29 09:33, Ted Lemon wrote:
>> On Jul 29, 2013, at 9:05 AM, Marcin Siodelski  =
wrote:
>>> According to RFC3315, server may use Relay-Reply message if it can't =
send Reconfigure directly to the client:
>>=20
>> Right.   That's a relay-reply message, not a reconfigure message.
> Yes, but the message type is irrelevant. Marcin's point was that
> the draft says that that server will never send a message that is not =
a
> response to a message from a relay, which is not true.
>=20
> Note that the draft says nothing about message types. Here's part of =
the
> text that needs to be updated in my opinion: "A standards-compliant =
DHCP
> server will never send a message to the a relay other than in response
> to a message from a relay,...".
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


--Apple-Mail-111--502907211
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Tomek =
,

Note that the =
draft says nothing about message types. Here's part of the
text that =
needs to be updated in my opinion: "A standards-compliant DHCP
server =
will never send a message to the a relay other than in response
to a =
message from a relay,...".

What do you =
think of the text:
NEW:
"A =
standards-complient DHCP server will never send a message to a relay for =
which the relay is the the intended =
recipient,  but is not able to recognize =
it."

Would it resolve the =
confusion?

Thanks,
Qi





On 2013-7-29, at =E4=B8=8A=E5=8D=889:49, Tomek Mrugalski =
wrote:

On 13-07-29 09:33, Ted Lemon wrote:
On Jul 29, 2013, at 9:05 AM, Marcin Siodelski <msiodelski@gmail.com> =
wrote:
According to RFC3315, server may use Relay-Reply message =
if it can't send Reconfigure directly to the =
client:

Right. =
  That's a relay-reply message, not a reconfigure =
message.
Yes, but the message type is irrelevant. =
Marcin's point was that
the draft says that that server will never =
send a message that is not a
response to a message from a relay, =
which is not true.

Note that the draft says nothing about message =
types. Here's part of the
text that needs to be updated in my =
opinion: "A standards-compliant DHCP
server will never send a message =
to the a relay other than in response
to a message from a =
relay,...".

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

=

--Apple-Mail-111--502907211--

From volz@cisco.com  Mon Jul 29 02:14: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 3481C21F9AE2 for ; Mon, 29 Jul 2013 02:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3K66MPVLnEP for ; Mon, 29 Jul 2013 02:14:37 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9237021F9966 for ; Mon, 29 Jul 2013 02:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13679; q=dns/txt; s=iport; t=1375089277; x=1376298877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WotizjiBuz0pBosuaVpn4UJYGMe8JSKXpgdjYx0WW+I=; b=W5pJbckE1fzePEIzK51loCcYgqyF3UZdwtnC8axc4w5j0JCikdNWLdEj 4cfe+6+8ykC8+xseA+HIbwFpSpYJdcICWuKAC9ByN2fw8gZkS2uaJFJEQ XVxjLhBqP3urjZsbVPrjZB2F1VpKNkikHgjnaYH78eSVw8QDO80K3GIwC Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAOwx9lGtJV2c/2dsb2JhbABRCoMGNYNgukaBFRZ0giUBAQQBAQEeAUwLEAIBCCcYAgMCIQYLFBECBA4Fh34DDwyKcZtAAYguDYhaBI0VgS+BNQQHgmI2bwOVdoFpjCaFJoMU
X-IronPort-AV: E=Sophos;i="4.89,768,1367971200";  d="scan'208,217";a="240521415"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jul 2013 09:14:37 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6T9Ebkr017305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 09:14:37 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 04:14:36 -0500
From: "Bernie Volz (volz)" 
To: Qi Sun 
Thread-Topic: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
Thread-Index: AQHOjDp6Y5trO2fg+0erLro62xl36Zl7X6JL
Date: Mon, 29 Jul 2013 09:14:36 +0000
Message-ID: 
References: ,  <59AC99E8-885D-4D18-9C4A-3AE649F9FA95@cisco.com>, <9EF31D11-CBF7-41FD-BB64-71D69FB015C1@gmail.com>
In-Reply-To: <9EF31D11-CBF7-41FD-BB64-71D69FB015C1@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_FDA28DBDD84D4B6EA3949BD7E90D5E54ciscocom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 09:14:43 -0000

--_000_FDA28DBDD84D4B6EA3949BD7E90D5E54ciscocom_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

One example was the text about standards compliant server not sending msgs.

I really think keeping it much simpler to say a relay that receives a msg t=
hat is not a relay-forw, relay-reply, or other message explicitly intended =
to be processed by the relay as per some RFC should forward the message in =
a Relay-Forw.

Future documents may define messages that a relay must process (rather than=
 forwarding), though existing relays will forward these until updated. Serv=
ers must drop packets that they are not to process.

That's about it.

- Bernie (from iPhone)

On Jul 29, 2013, at 11:03 AM, "Qi Sun" > wrote:

Hi Bernie,

I wonder if reworking the draft a bit would be worthwhile. In some cases it=
 makes statements that could be dangerous in the long run.

Would you please elaborate so that we could work on them?


Best Regards,
Qi Sun


On 2013-7-29, at =1B$B>e8a=1B(B10:32, Bernie Volz (volz) wrote:

I wonder if reworking the draft a bit would be worthwhile. In some cases it=
 makes statements that could be dangerous in the long run.

The basic concept is that a received msg is either forwarded or consumed by=
 relay.

If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how to han=
dle it.

If not one of these and not one to be consumed by relay (ie, Reconfigure-Re=
ply), it should be forwarded (Relay-forw) unless policy disallows (ie, not =
client facing interface).

- Bernie (from iPhone)

On Jul 29, 2013, at 10:08 AM, "Qi Sun" > wrote:


Hi Marcin ,

Thanks for the review!

It would be good to distinguish between the term "intended recipient" and "=
recipient". From the context I understand that the intended recipient is us=
ed with regards to the target for the message being passed through relays a=
nd the recipient is a term used to describe a host which is currently holdi=
ng a message. Perhaps this clarification could be placed in the glossary or=
 somewhere in the text?

Consider this:
"... the message is valid for constructing a new Relay-forward message if t=
he recipient is a relay agent, the relay agent does not identify itself as =
the intended recipient, and the message is not a Relay-Reply message".

There is a mix-up of these two terms which may suggest that the message is =
sent to a wrong relay which is  not an "intended recipient", while the sent=
ence is actually meant to tell that the relay is not a target for the messa=
ge being encapsulated.

How about the following text:

"... the message is valid for constructing a new Relay-forward message if a=
 relay agent receives the message, but the relay agent does not identify it=
self as the target of the message, and the message is not a Relay-Reply mes=
sage."

Is the usage of 'target' here is precise?

Best Regards,
Qi

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


--_000_FDA28DBDD84D4B6EA3949BD7E90D5E54ciscocom_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable







One example was the text about standards compliant server not sending =
msgs.







I really think keeping it much simpler to say a relay that receives a =
msg that is not a relay-forw, relay-reply, or other message explicitly inte=
nded to be processed by the relay as per some RFC should forward the messag=
e in a Relay-Forw. 







Future documents may define messages that a relay must process (rather=
 than forwarding), though existing relays will forward these until updated.=
 Servers must drop packets that they are not to process.







That's about it.



- Bernie (from iPhone)




On Jul 29, 2013, at 11:03 AM, "Qi Sun" <sunqi.csnet.thu@gmail.com> wrote:










Hi Bernie,








I wonder if reworking the draft a bit would be worthwhile. In some cas=
es it makes statements that could be dangerous in the long run. 










Would you please elaborate so that we could work on them?






















Best Regards,

Qi Sun
















On 2013-7-29, at =1B$B>e8a=1B(B10:32, Bernie Volz (volz) wrote:








I wonder if reworking the draft a bit would be worthwhile. In some cas=
es it makes statements that could be dangerous in the long run. 







The basic concept is that a received msg is either forwarded or consum=
ed by relay.







If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how t=
o handle it.







If not one of these and not one to be consumed by relay (ie, Reconfigu=
re-Reply), it should be forwarded (Relay-forw) unless policy disallows (ie,=
 not client facing interface).



- Bernie (from iPhone)




On Jul 29, 2013, at 10:08 AM, "Qi Sun" <sunqi.csnet.thu@gmail.com> wrote:





















Hi Marcin ,







Thanks for the review! 





















It would be good to distinguish between the term "inte=
nded recipient" and "recipient". From the context I understa=
nd that the intended recipient is used with regards to the target for the m=
essage being passed through relays and the recipient is
 a term used to describe a host which is currently holding a message. Perha=
ps this clarification could be placed in the glossary or somewhere in the t=
ext?







Consider this:


"... the message is valid for constructing a new Relay=
-forward message if the recipient is a relay agent, the relay agent does no=
t identify itself as the intended recipient, and the message is not a Relay=
-Reply message".







There is a mix-up of these two terms which may suggest that=
 the message is sent to a wrong relay which is  not an "intended =
recipient", while the sentence is actually meant to tell that the rela=
y is not a target for the message being encapsulated.











How about the following text:







"... the message is valid for constructing a new Relay-forward message=
 if a relay agent receives the message, but the relay agent
 does not identify itself as the target of the message, and the message is=
 not a Relay-Reply message."







Is the usage of 'target' here is precise? 







Best Regards,


Qi












_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg




















--_000_FDA28DBDD84D4B6EA3949BD7E90D5E54ciscocom_--

From volz@cisco.com  Mon Jul 29 02:21:21 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 5434D11E80E9 for ; Mon, 29 Jul 2013 02:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76tTD-8a7azR for ; Mon, 29 Jul 2013 02:21:15 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8121F9FE1 for ; Mon, 29 Jul 2013 02:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15550; q=dns/txt; s=iport; t=1375089650; x=1376299250; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CUc+DzuxWbsks3TfPvrsKyhw2c9kJl2awa5WlfnZAu0=; b=jEWyMcZ+ecErNE95NuGmyfl3QSCRJ+T7AiSuVUnTm8d2ugZZTO2y6ynV vdkrLLwIZEls6ePtCSuuloKxysX0T5fbT43yqbWXqCZrXuoBb9+g0G6Zf 70xLbifCOcFiJ2u9XAJiCQSVW0ma9qLFMaB7Zn5rOTxvIy/+N5kHep6qm s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAJky9lGtJXG9/2dsb2JhbABRCoMGNYNgukeBFRZ0giUBAQQBAQEeAUwLEAIBCCcYAgMCIQYLFBECBA4Fh34DDwyKdJtAAYguDYhaBI0VgS+BNQQHgmI2bwOVdoFpjCaFJoMU
X-IronPort-AV: E=Sophos;i="4.89,768,1367971200";  d="scan'208,217";a="237717037"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2013 09:20:34 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6T9KX76019721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 09:20:33 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 04:20:33 -0500
From: "Bernie Volz (volz)" 
To: Qi Sun 
Thread-Topic: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
Thread-Index: AQHOjDp6Y5trO2fg+0erLro62xl36Zl7X6JLgAABqo0=
Date: Mon, 29 Jul 2013 09:20:33 +0000
Message-ID: <05BEE5B5-FFF0-4894-AB20-8BEC6ACE8A41@cisco.com>
References: ,  <59AC99E8-885D-4D18-9C4A-3AE649F9FA95@cisco.com>, <9EF31D11-CBF7-41FD-BB64-71D69FB015C1@gmail.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_05BEE5B5FFF04894AB208BEC6ACE8A41ciscocom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 09:21:21 -0000

--_000_05BEE5B5FFF04894AB208BEC6ACE8A41ciscocom_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

BTW - it may be useful to assure relays have configuration as to whether th=
ey do forwarding (Relay-Forw) for specific interfaces; for example this set=
ting should be off if dhcp clients are not expected to be on a particular i=
nterface.

This would assure that on server facing interfaces, a future server to rela=
y message which the relay doesn't support isn't forwarded back to server (b=
ut not a big deal if it happens as server must ignore that msg).

- Bernie (from iPhone)

On Jul 29, 2013, at 11:14 AM, "Bernie Volz (volz)" > wrote:

One example was the text about standards compliant server not sending msgs.

I really think keeping it much simpler to say a relay that receives a msg t=
hat is not a relay-forw, relay-reply, or other message explicitly intended =
to be processed by the relay as per some RFC should forward the message in =
a Relay-Forw.

Future documents may define messages that a relay must process (rather than=
 forwarding), though existing relays will forward these until updated. Serv=
ers must drop packets that they are not to process.

That's about it.

- Bernie (from iPhone)

On Jul 29, 2013, at 11:03 AM, "Qi Sun" > wrote:

Hi Bernie,

I wonder if reworking the draft a bit would be worthwhile. In some cases it=
 makes statements that could be dangerous in the long run.

Would you please elaborate so that we could work on them?


Best Regards,
Qi Sun


On 2013-7-29, at =1B$B>e8a=1B(B10:32, Bernie Volz (volz) wrote:

I wonder if reworking the draft a bit would be worthwhile. In some cases it=
 makes statements that could be dangerous in the long run.

The basic concept is that a received msg is either forwarded or consumed by=
 relay.

If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how to han=
dle it.

If not one of these and not one to be consumed by relay (ie, Reconfigure-Re=
ply), it should be forwarded (Relay-forw) unless policy disallows (ie, not =
client facing interface).

- Bernie (from iPhone)

On Jul 29, 2013, at 10:08 AM, "Qi Sun" > wrote:


Hi Marcin ,

Thanks for the review!

It would be good to distinguish between the term "intended recipient" and "=
recipient". From the context I understand that the intended recipient is us=
ed with regards to the target for the message being passed through relays a=
nd the recipient is a term used to describe a host which is currently holdi=
ng a message. Perhaps this clarification could be placed in the glossary or=
 somewhere in the text?

Consider this:
"... the message is valid for constructing a new Relay-forward message if t=
he recipient is a relay agent, the relay agent does not identify itself as =
the intended recipient, and the message is not a Relay-Reply message".

There is a mix-up of these two terms which may suggest that the message is =
sent to a wrong relay which is  not an "intended recipient", while the sent=
ence is actually meant to tell that the relay is not a target for the messa=
ge being encapsulated.

How about the following text:

"... the message is valid for constructing a new Relay-forward message if a=
 relay agent receives the message, but the relay agent does not identify it=
self as the target of the message, and the message is not a Relay-Reply mes=
sage."

Is the usage of 'target' here is precise?

Best Regards,
Qi

_______________________________________________
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

--_000_05BEE5B5FFF04894AB208BEC6ACE8A41ciscocom_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable







BTW - it may be useful to assure relays have configuration as to wheth=
er they do forwarding (Relay-Forw) for specific interfaces; for example thi=
s setting should be off if dhcp clients are not expected to be on a particu=
lar interface.







This would assure that on server facing interfaces, a future server to=
 relay message which the relay doesn't support isn't forwarded back to serv=
er (but not a big deal if it happens as server must ignore that msg).



- Bernie (from iPhone)




On Jul 29, 2013, at 11:14 AM, "Bernie Volz (volz)" <volz@cisco.com> wrote:










One example was the text about standards compliant server not sending =
msgs.







I really think keeping it much simpler to say a relay that receives a =
msg that is not a relay-forw, relay-reply, or other message explicitly inte=
nded to be processed by the relay as per some RFC should forward the messag=
e in a Relay-Forw. 







Future documents may define messages that a relay must process (rather=
 than forwarding), though existing relays will forward these until updated.=
 Servers must drop packets that they are not to process.







That's about it.



- Bernie (from iPhone)




On Jul 29, 2013, at 11:03 AM, "Qi Sun" <sunqi.csnet.thu@gmail.com> wrote:










Hi Bernie,








I wonder if reworking the draft a bit would be worthwhile. In some cas=
es it makes statements that could be dangerous in the long run. 










Would you please elaborate so that we could work on them?






















Best Regards,

Qi Sun
















On 2013-7-29, at =1B$B>e8a=1B(B10:32, Bernie Volz (volz) wrote:








I wonder if reworking the draft a bit would be worthwhile. In some cas=
es it makes statements that could be dangerous in the long run. 







The basic concept is that a received msg is either forwarded or consum=
ed by relay.







If the message is a Relay-forw or Relay-Reply, RFC 3315 explains how t=
o handle it.







If not one of these and not one to be consumed by relay (ie, Reconfigu=
re-Reply), it should be forwarded (Relay-forw) unless policy disallows (ie,=
 not client facing interface).



- Bernie (from iPhone)




On Jul 29, 2013, at 10:08 AM, "Qi Sun" <sunqi.csnet.thu@gmail.com> wrote:





















Hi Marcin ,







Thanks for the review! 





















It would be good to distinguish between the term "inte=
nded recipient" and "recipient". From the context I understa=
nd that the intended recipient is used with regards to the target for the m=
essage being passed through relays and the recipient is
 a term used to describe a host which is currently holding a message. Perha=
ps this clarification could be placed in the glossary or somewhere in the t=
ext?







Consider this:


"... the message is valid for constructing a new Relay=
-forward message if the recipient is a relay agent, the relay agent does no=
t identify itself as the intended recipient, and the message is not a Relay=
-Reply message".







There is a mix-up of these two terms which may suggest that=
 the message is sent to a wrong relay which is  not an "intended =
recipient", while the sentence is actually meant to tell that the rela=
y is not a target for the message being encapsulated.











How about the following text:







"... the message is valid for constructing a new Relay-forward message=
 if a relay agent receives the message, but the relay agent
 does not identify itself as the target of the message, and the message is=
 not a Relay-Reply message."







Is the usage of 'target' here is precise? 







Best Regards,


Qi












_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg
























_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg








--_000_05BEE5B5FFF04894AB208BEC6ACE8A41ciscocom_--

From msiodelski@gmail.com  Mon Jul 29 04:12: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 C6C8321F967F for ; Mon, 29 Jul 2013 04:12:50 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTMs8Xa+hC5v for ; Mon, 29 Jul 2013 04:12:50 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0925C21F99AE for ; Mon, 29 Jul 2013 04:12:35 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id v1so248746lbd.10 for ; Mon, 29 Jul 2013 04:12:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hiBUhSCufBuZg2DDUx12agsdl1UiLWXlZUV+da6ZtHU=; b=UXzIWPtXL86MUQo85+tpdlj59Q2pxkdz2IRLrdxQl51JaQMsCvSMJrZFApvlZlw74G zb9JuTp62JmTwqR2ifPM/pdb/VZtyKysPEgpLeT/15DNPVYyXKHxa2OK8hWwHsFVCbYZ 4GDuEFrH4osk/5BvQiSRnY/fKJjp7Avu/Ma1oMEoqWhPbLVGUKyxRkUfyirXQYRij/iL NIfuREgIqK3thSTFeC460KoqDS341gDcvvuDp78tcvOBjxtNdBw0xG/3RGG5Kmv74mjd Xqpj1GomC07vJp/4nhrSDRqG+kLyoIoduQFMjxmGaM5Jz71LUzYKGWJJetpcaK+m2ykv 74/g==
MIME-Version: 1.0
X-Received: by 10.112.63.2 with SMTP id c2mr25243983lbs.6.1375096354904; Mon, 29 Jul 2013 04:12:34 -0700 (PDT)
Received: by 10.112.202.170 with HTTP; Mon, 29 Jul 2013 04:12:34 -0700 (PDT)
In-Reply-To: <1CBE1E84-BAF6-4447-89D7-A9AA1B371F74@gmail.com>
References:  <8D23D4052ABE7A4490E77B1A012B6307752334C7@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B63077523396E@mbx-01.win.nominum.com> <51F61E9A.4040105@gmail.com> <1CBE1E84-BAF6-4447-89D7-A9AA1B371F74@gmail.com>
Date: Mon, 29 Jul 2013 13:12:34 +0200
Message-ID: 
From: Marcin Siodelski 
To: Qi Sun 
Content-Type: multipart/alternative; boundary=001a11c3e880c41e8c04e2a49188
Cc: "" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 11:12:51 -0000

--001a11c3e880c41e8c04e2a49188
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jul 29, 2013 at 10:04 AM, Qi Sun  wrote:

>
> Hi Tomek ,
>
> > Yes, but the message type is irrelevant. Marcin's point was that
> > the draft says that that server will never send a message that is not a
> > response to a message from a relay, which is not true.
>
> What the server sends out is a Relay-Reply message, rather than a
> Reconfigure message. The Relay-reply message is the message that in
> response to the relay agent.
>
> We circle around the actual problem. Yes, the Relay-reply is most of the
time sent in response to the relay agent, but there are some cases when the
server initiates the communication and sends the Relay-reply message which
 is not generated as a response to the message sent from relay (RFC3315,
19.1.1).
Note that this doesn't change anything in the definition of the "valid"
message that you specify in the draft. It only invalidates the statement in
one of the bullets that explain why the definition has been specified as it
is.

Marcin

--001a11c3e880c41e8c04e2a49188
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Jul 29, 2013 at 10:04 AM, Qi Sun <sunqi.c=
snet.thu@gmail.com> wrote:




Hi Tomek ,




> Yes, but the message type is irrelevant. Marcin's point was that
> the draft says that that server will never send a message that is not =
a

> response to a message from a relay, which is not true.




What the server sends out is a Relay-Reply message, rather than a Rec=
onfigure message. The Relay-reply message is the message that in response t=
o the relay agent.

We circle around the actu=
al problem. Yes, the Relay-reply is most of the time sent in response to th=
e relay agent, but there are some cases when the server initiates the commu=
nication and sends the Relay-reply message which =A0is not generated as a r=
esponse to the message sent from relay (RFC3315, 19.1.1).


Note that this doesn't change anything in the definition of =
the "valid" message that you specify in the draft. It only invali=
dates the statement in one of the bullets that explain why the definition h=
as been specified as it is.=A0



Marcin


--001a11c3e880c41e8c04e2a49188--

From msiodelski@gmail.com  Mon Jul 29 04:18:41 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 188C021F9AE9 for ; Mon, 29 Jul 2013 04:18:41 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jpy3eOFGu0D for ; Mon, 29 Jul 2013 04:18:40 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1B34E21F9B60 for ; Mon, 29 Jul 2013 04:18:31 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id fs13so4003627lab.30 for ; Mon, 29 Jul 2013 04:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RNkxMQ7FJ4jGWoFJQTsGcV/4OQDAQv7UFN8VnoytLPw=; b=F8dl+rmy/xcYSJAJa/wOYE3IbZnd6HJRVckVuQ+Toi5uGMoB0ag23nKnuKhlsQ78/t gtpAt56Fzfm5Mbv8Zwm4S4t0HLGlTiZAKuqiqtwmwQ3CkoJD2SBb9p0CaZS/jdlfH8iI x/WyreML6hcE5KSOxJMr7VxYS6v7TrDeASFaaLZj/qiV1W+8xQes+A3F7kw1LDvsS37Z xupiV4yw8VgaB7age5U0/SJHffGrVLhG8TdSs8QfKX7iQvOGSWOKX+ScrJBXQhmhTNV1 Ott1o8DM6cCf8wWaisLN63MBlBN6iaRNdihSuYFpbNN4yJKd4Ig+rwpR9oGBmsEVTPmL CpLw==
MIME-Version: 1.0
X-Received: by 10.152.29.103 with SMTP id j7mr3600128lah.7.1375096710935; Mon, 29 Jul 2013 04:18:30 -0700 (PDT)
Received: by 10.112.202.170 with HTTP; Mon, 29 Jul 2013 04:18:30 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 29 Jul 2013 13:18:30 +0200
Message-ID: 
From: Marcin Siodelski 
To: Qi Sun 
Content-Type: multipart/alternative; boundary=089e0160b828fcb97704e2a4a62d
Cc: "" , "" , Ted Lemon 
Subject: Re: [dhcwg] Some comments regarding draft-ietf-dhc-dhcpv6-unknown-msg-01
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, 29 Jul 2013 11:18:41 -0000

--089e0160b828fcb97704e2a4a62d
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jul 29, 2013 at 10:06 AM, Qi Sun  wrote:

> How about the following text:
>
> "... the message is valid for constructing a new Relay-forward message if
> a relay agent receives the message, but the relay agent does not identify
> itself as the target of the message, and the message is not a Relay-Reply
> message."
>
> Is the usage of 'target' here is precise?
>
> Yes. It sounds much clearer now.

--089e0160b828fcb97704e2a4a62d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Jul 29, 2013 at 10:06 AM, Qi Sun <sunqi.c=
snet.thu@gmail.com> wrote:










How about the follow=
ing text:

"...=A0t=
he message is valid for constructing a new=A0Relay-forward message if a relay agent receives the message, but=
 the relay=A0agent does not identi=
fy itself as the target of the message, and the=A0message is not a Relay-Reply message."



Is the usage of 'target' here is precise?=A0

Yes. It sounds much c=
learer now. =A0



--089e0160b828fcb97704e2a4a62d--

From internet-drafts@ietf.org  Mon Jul 29 04:27:30 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 7F55821E8089; Mon, 29 Jul 2013 04:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.472
X-Spam-Level: 
X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LkEwlozlr82; Mon, 29 Jul 2013 04:27:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD8E21E8095; Mon, 29 Jul 2013 04:27:07 -0700 (PDT)
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.60p1
Message-ID: <20130729112707.11897.92917.idtracker@ietfa.amsl.com>
Date: Mon, 29 Jul 2013 04:27:07 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-14.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, 29 Jul 2013 11:27:30 -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 Agent
	Author(s)       : Leaf Y. Yeh
                          Mohamed Boucadair
	Filename        : draft-ietf-dhc-dhcpv6-radius-opt-14.txt
	Pages           : 11
	Date            : 2013-07-29

Abstract:
   The DHCPv6 RADIUS option provides a mechanism to exchange
   authorization and identification information between DHCPv6 relay
   agent and DHCPv6 server.  This architecture assumes that the Network
   Access Server(NAS) acts as both DHCPv6 relay agent and RADIUS client.
   When receiving messages from the DHCPv6 clients, the NAS consults the
   RADIUS server and adds the RADIUS response when forwarding the DHCPv6
   client's messages to the DHCPv6 server.  The DHCPv6 server then uses
   that additional information to generate appropriate response to the
   DHCPv6 client's requests.


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-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From list-dhcwg@dragon.net  Mon Jul 29 07:38:00 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 8063C21F9AEF for ; Mon, 29 Jul 2013 07:38:00 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQopS8O5sFuE for ; Mon, 29 Jul 2013 07:37:59 -0700 (PDT)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8E11E80E6 for ; Mon, 29 Jul 2013 07:37:44 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 9A12A3740049; Mon, 29 Jul 2013 07:37:39 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id C761026DBDC6; Mon, 29 Jul 2013 16:37:38 +0200 (CEST)
Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id C153F26DBDC5; Mon, 29 Jul 2013 16:37:38 +0200 (CEST)
To: "Bernie Volz (volz)" 
From: Paul Ebersman 
In-reply-to: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E185ECB4B@xmb-rcd-x04.cisco.com>
Comments: In-reply-to "Bernie Volz (volz)"  message dated "Fri, 19 Jul 2013 13:59:20 -0000."
X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22)
Date: Mon, 29 Jul 2013 16:37:38 +0200
Message-Id: <20130729143738.C761026DBDC6@fafnir.remote.dragon.net>
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 29 Jul 2013 14:38:00 -0000

volz> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
volz> ([[http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design]])
volz> believe it is ready for working group last call. Please review
volz> this draft and indicate whether or not you feel it is ready to be
volz> published. Your input is important!

I have read this document and support it going forward.

From volz@cisco.com  Mon Jul 29 08:13:02 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 95A8611E8109 for ; Mon, 29 Jul 2013 08:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcpDI+K5P3ZZ for ; Mon, 29 Jul 2013 08:12:56 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5321221F99CF for ; Mon, 29 Jul 2013 08:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7345; q=dns/txt; s=iport; t=1375110771; x=1376320371; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xIX1Gn5g/A3tf40sUn55dD2AN9lDoot9VZiBHVFNokM=; b=gLmwIwIQyp1SGEv0PKY2GGk2rwaMT19Q8kQysM4ulbiwGrfU3tzK3Wyn IatHukjk4kKwSFnRYG90fJMIDx2Eh7VekBLJlqtrqwshCnBqLxZQhoVMA /Drb8vP33p9C55EBdzG8fEpJkppY+pTEoQzz/KiMEPreSBd5JjjUW1XrZ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlcFAA+G9lGtJXG9/2dsb2JhbABbgkJENbVtiDqBGBZ0giUBAQQtXAIBCD8HMhQRAgQTiBAMuEuPeQoBgxhvA5dfgSmQI4MU
X-IronPort-AV: E=Sophos;i="4.89,770,1367971200";  d="scan'208,217";a="237843513"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2013 15:12:51 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6TFCoNE023070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 15:12:50 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 10:12:50 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: Berlin IETF - Note taker needed
Thread-Index: AQHOjG4WR5D1lQH7S0m7waNnglvFvw==
Date: Mon, 29 Jul 2013 15:12:50 +0000
Message-ID: <2D7647A9-02FF-49A0-AA6F-2DEB19C828AC@cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E185EBC3E@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185EBC3E@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_2D7647A902FF49A0AA6F2DEB19C828ACciscocom_"
MIME-Version: 1.0
Subject: Re: [dhcwg] Berlin IETF - Note taker needed
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, 29 Jul 2013 15:13:02 -0000

--_000_2D7647A902FF49A0AA6F2DEB19C828ACciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

We still are looking for at least one person to take notes for the Thursday=
 session! We need your assistance!!

- Bernie

On Jul 19, 2013, at 4:53 AM, "Bernie Volz (volz)" > wrote:

Hi:

We need a scribe for taking notes for the minutes. We suggest use of etherp=
ad, but any form is fine. See http://tools.ietf.org/wg/dhc/minutes.

If you=92ll be at the Berlin session, we=92d greatly appreciate if you=92d =
volunteer to take notes for the minutes.

And please let us know in advance!


Also, if you have slides, please provide them to us (dhc-chairs@tools.ietf.=
org) so we can get them posted.

Updated agenda and a few of the presentations have been posted. See https:/=
/datatracker.ietf.org/meeting/87/agenda/dhc/ and https://datatracker.ietf.o=
rg/meeting/87/materials.html#wg-dhc.


-          Bernie

--_000_2D7647A902FF49A0AA6F2DEB19C828ACciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







We still are looking for at least one person to take notes for the Thu=
rsday session! We need your assistance!!



- Bernie




On Jul 19, 2013, at 4:53 AM, "Bernie Volz (volz)" <volz@cisco.com> wrote:














Hi:


 


We need a scribe for taking notes for the minutes. W=
e suggest use of etherpad, but any form is fine. See
http://tools.ietf.org/wg/d=
hc/minutes.


 


If you=92ll be at the Berlin session, we=92d grea=
tly appreciate if you=92d volunteer to take notes for the minutes.




 <=
/p>

And please let us =
know in advance!


 <=
/p>



 


Also, if you have slides, please provide them to us =
(dhc-chairs@tools.ietf.org=
) so we can get them posted.


 


Updated agenda and a few of the presentations have b=
een posted. See
https://dat=
atracker.ietf.org/meeting/87/agenda/dhc/ and
h=
ttps://datatracker.ietf.org/meeting/87/materials.html#wg-dhc.


 


-     =
;    
Bernie










--_000_2D7647A902FF49A0AA6F2DEB19C828ACciscocom_--

From alexandru.petrescu@gmail.com  Mon Jul 29 11:05:01 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 D29D421F9CA4 for ; Mon, 29 Jul 2013 11:05:00 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWkvIPrmClhd for ; Mon, 29 Jul 2013 11:04:59 -0700 (PDT)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA121F9BEF for ; Mon, 29 Jul 2013 11:04:54 -0700 (PDT)
Received: by mail-bk0-f50.google.com with SMTP id ik8so1296269bkc.9 for ; Mon, 29 Jul 2013 11:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G8FW14/hHUGPTIwNlEidMET7W+HbBFduyhSrPBnqriQ=; b=Zg+/Wc2+NnFt/026N1JPGKGjlSJada2jp3JOYuHUXcEe1WZvkMIXjR7M1q/dAKEVXs lnJPpkA/VkVlj/P1DwXbFSQz03dhiGkcR5AF9n2FSgcUvauIvNijRqUHYii3TvtMeFms sw9e63CVSbeLMRM01gOgRAjXQ3MWnIKcgSkOB0J3KN3gJsrgO279r4bzzOAhh9FLGSj4 OVvTqQOct4QaimVYpfEKttdQqMX3O8GyJYV51kYWXUj6YvHrH8OLYEwC4xOSfA2alWCa VGDI8XBCLqSsOob1PAGgHW63H+4HmUYLeug7d1Ttz3c+B+DQ3yDdz+QVdZEGmj99lwdp +Psg==
X-Received: by 10.204.70.1 with SMTP id b1mr8891178bkj.3.1375121093862; Mon, 29 Jul 2013 11:04:53 -0700 (PDT)
Received: from [192.168.15.144] ([213.23.104.157]) by mx.google.com with ESMTPSA id m6sm16318607bki.7.2013.07.29.11.04.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 11:04:53 -0700 (PDT)
Message-ID: <51F6AEAF.3020102@gmail.com>
Date: Mon, 29 Jul 2013 20:04:31 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> <4C872C87-9D7E-473C-86CE-F1D7CD7FCCA9@gmail.com> <51546BEF.2000206@gmail.com>
In-Reply-To: <51546BEF.2000206@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP
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, 29 Jul 2013 18:05:02 -0000

Any news about IEEE 802.11ai and DHCP?

Has the TGai provided a generic container framework to quickly transfer
DHCP messages?

Alex

Le 28/03/2013 17:12, Alexandru Petrescu a écrit :
> Le 26/03/2013 10:09, Jouni Korhonen a écrit :
>>
>> I find it quite interesting and slightly surprising IEEE is
>> working on this. In cellular space (3gpp) we have had about
>> equivalent mechanism at the NAS protocol layer from the beginning.
>
> I tend to agree.
>
> For example, there is this link-layer RANAP protocol.  In this, the
> UserEquipment sends a "Activate PDP Context Request" with a "DNS
> Server IPv6 Address Request", and receives the IPv6 address of the
> DNS Server in a "Activate PDP Context Accept".
>
> This link-layer messaging is redundant with two other IP protocols:
> (1) Router Advertisement sending the DNS IPv6 address (RFC61606 "IPv6
> Router Advertisement Options for DNS Configuration") _and_ with (2)
> DHCPv6 configuration options containing the address of the DNS
> server.
>
>> It works but has always been a bit of headache, since multiple
>> ways to do the same thing with loads of optional features on
>> different layers caused nasty implementation/deployment challenges.
>> I hope IEEE does this better now that they are doing it ;)
>
> I think that _if_ at IETF there were such protocol to realize this
> fast configuration in the same way that IEEE needs for crowded
> hotspot then one could suggest it to IEEE.
>
> Alex
>
>>
>> - Jouni
>>
>>
>> On Feb 12, 2013, at 10:25 PM, Hiroki Nakano 
>> wrote:
>>
>>> Dear all,
>>>
>>> I'm participating in IEEE 802.11 WG TGai task group which is for
>>> FILS (Fast Initiali Link Setup). They are working for speeding
>>> up of 802.11 process and trying to provide a new framework for
>>> higher layer protocols.
>>>
>>> I'd like to introduce the overview of prospective 802.11ai
>>> specification and discuss usages of DHCP on it with DHC WG
>>> people in March. The followings are a brief introduction.
>>>
>>> TGai supposes Wireless LAN is used in very crowded envirionment
>>> such as railway stations in a giant metropolis. TGai also
>>> supposes moving hosts through the front of Access Points. In
>>> these cases, it is effective to reduce management frames of
>>> 802.11, especially frames for probing APs, authentication and
>>> association. The current framework takes a few seconds to set up
>>> network connectivity before starting to communicate. The target
>>> of TGai is under one second.
>>>
>>> TGai is trying to reduce management frames of 802.11 itself, and
>>> in addition provide framework for higher layers such as IP to
>>> send and receive packets during 802.11 association process. The
>>> currently proposed framework provides "ONE round-trip packet
>>> exchange" by piggybacking on 802.11 Association Request/Response
>>> frames.
>>>
>>> My interest is how to fit DHCP to this framework. In case of
>>> DHCPv4, this is achieved by using Rapid Commit Option (RFC4039)
>>> and making some additional and trivial rules. In case of DHCPv6,
>>> we have to use both RA and DHCPv6. In addition, DAD and randomly
>>> generated addresses have to be considered. Share your idea,
>>> please.
>>>
>>> 802.11 TGai is still going on and its specification is subject
>>> to change, but I'd like to discuss in IETF DHCP issues related
>>> to 802.11ai and arrange I-D according to the progress of TGai
>>> task group.
>>>
>>> Regards,
>>>
>>> Hiroki Nakano Trans New Technology, Inc. 
>>>
>>> _______________________________________________ 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 cas@trans-nt.com  Mon Jul 29 22:13: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 7321211E8174 for ; Mon, 29 Jul 2013 22:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level: 
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7-+GdFBNO-h for ; Mon, 29 Jul 2013 22:13:06 -0700 (PDT)
Received: from dump.fs.trans-nt.com (smtp.trans-nt.co.jp [202.10.98.251]) by ietfa.amsl.com (Postfix) with SMTP id 6685911E81B9 for ; Mon, 29 Jul 2013 22:13:00 -0700 (PDT)
Received: (qmail 56983 invoked from network); 30 Jul 2013 14:12:50 +0900
Received: from red.fs.trans-nt.co.jp (HELO platinum.local) (202.10.98.240) by smtp.trans-nt.co.jp with SMTP; 30 Jul 2013 14:12:50 +0900
Message-ID: <51F74B4F.40004@trans-nt.com>
Date: Tue, 30 Jul 2013 14:12:47 +0900
From: Hiroki Nakano 
Organization: cas authorized 53a6c6e30f1471298320e605c741e412
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> <4C872C87-9D7E-473C-86CE-F1D7CD7FCCA9@gmail.com> <51546BEF.2000206@gmail.com> <51F6AEAF.3020102@gmail.com>
In-Reply-To: <51F6AEAF.3020102@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP
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, 30 Jul 2013 05:13:11 -0000

Thank you for remembering 802.11ai :)

At the last meeting on IEEE802.11WG in Geneva, July,
TGai finished its internal work for Draft 1.0.
According to this draft, 802.11 will have capability
to convey L3 packets by Association Request/Response frame.
Just in my personal opinion, I think this feature will not
change so much in the future process of 802.11.

I'm trying to fix experimentally DHCPv4 client/server to
support RCO. In addition, DHCP client should start when
WLAN layer decides to connect some BSS and to start
an association process, that is, when the link-up flag
of the interface is still off. Moreover, DHCP client has to
pass the first packet to WLAN layer by 802.11's MLME API
defined in TGai.
DHCP and WLAN layer need close collaboration
and possiblly need discussion for implementation.

And, how about IPv6...?

Regards,

Hiroki Nakano
Trans New Technology, Inc. 


(13/07/30 3:04), Alexandru Petrescu wrote:
> Any news about IEEE 802.11ai and DHCP?
>
> Has the TGai provided a generic container framework to quickly transfer
> DHCP messages?
>
> Alex
>
> Le 28/03/2013 17:12, Alexandru Petrescu a écrit :
>> Le 26/03/2013 10:09, Jouni Korhonen a écrit :
>>>
>>> I find it quite interesting and slightly surprising IEEE is
>>> working on this. In cellular space (3gpp) we have had about
>>> equivalent mechanism at the NAS protocol layer from the beginning.
>>
>> I tend to agree.
>>
>> For example, there is this link-layer RANAP protocol.  In this, the
>> UserEquipment sends a "Activate PDP Context Request" with a "DNS
>> Server IPv6 Address Request", and receives the IPv6 address of the
>> DNS Server in a "Activate PDP Context Accept".
>>
>> This link-layer messaging is redundant with two other IP protocols:
>> (1) Router Advertisement sending the DNS IPv6 address (RFC61606 "IPv6
>> Router Advertisement Options for DNS Configuration") _and_ with (2)
>> DHCPv6 configuration options containing the address of the DNS
>> server.
>>
>>> It works but has always been a bit of headache, since multiple
>>> ways to do the same thing with loads of optional features on
>>> different layers caused nasty implementation/deployment challenges.
>>> I hope IEEE does this better now that they are doing it ;)
>>
>> I think that _if_ at IETF there were such protocol to realize this
>> fast configuration in the same way that IEEE needs for crowded
>> hotspot then one could suggest it to IEEE.
>>
>> Alex
>>
>>>
>>> - Jouni
>>>
>>>
>>> On Feb 12, 2013, at 10:25 PM, Hiroki Nakano 
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I'm participating in IEEE 802.11 WG TGai task group which is for
>>>> FILS (Fast Initiali Link Setup). They are working for speeding
>>>> up of 802.11 process and trying to provide a new framework for
>>>> higher layer protocols.
>>>>
>>>> I'd like to introduce the overview of prospective 802.11ai
>>>> specification and discuss usages of DHCP on it with DHC WG
>>>> people in March. The followings are a brief introduction.
>>>>
>>>> TGai supposes Wireless LAN is used in very crowded envirionment
>>>> such as railway stations in a giant metropolis. TGai also
>>>> supposes moving hosts through the front of Access Points. In
>>>> these cases, it is effective to reduce management frames of
>>>> 802.11, especially frames for probing APs, authentication and
>>>> association. The current framework takes a few seconds to set up
>>>> network connectivity before starting to communicate. The target
>>>> of TGai is under one second.
>>>>
>>>> TGai is trying to reduce management frames of 802.11 itself, and
>>>> in addition provide framework for higher layers such as IP to
>>>> send and receive packets during 802.11 association process. The
>>>> currently proposed framework provides "ONE round-trip packet
>>>> exchange" by piggybacking on 802.11 Association Request/Response
>>>> frames.
>>>>
>>>> My interest is how to fit DHCP to this framework. In case of
>>>> DHCPv4, this is achieved by using Rapid Commit Option (RFC4039)
>>>> and making some additional and trivial rules. In case of DHCPv6,
>>>> we have to use both RA and DHCPv6. In addition, DAD and randomly
>>>> generated addresses have to be considered. Share your idea,
>>>> please.
>>>>
>>>> 802.11 TGai is still going on and its specification is subject
>>>> to change, but I'd like to discuss in IETF DHCP issues related
>>>> to 802.11ai and arrange I-D according to the progress of TGai
>>>> task group.
>>>>
>>>> Regards,
>>>>
>>>> Hiroki Nakano Trans New Technology, Inc. 
>>>>
>>>> _______________________________________________ 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 shwethab@cisco.com  Tue Jul 30 00:38: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 0F72D11E80F4 for ; Tue, 30 Jul 2013 00:38:27 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+9ucyepJxE4 for ; Tue, 30 Jul 2013 00:38:22 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE4F21F9FE1 for ; Tue, 30 Jul 2013 00:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=768; q=dns/txt; s=iport; t=1375169902; x=1376379502; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Il0q5/lF2bNeZDaGdJSiKcPYxOEyLtVW4pnwIWUz6O4=; b=bCgkMq2xycg6V73uqAn0Eo9PdsHoCOk120Vkw/uZ5a+tTa0safdNGQBh tdg7YqsLj0N9u3xo4EolTwiluIL38wij+gsmWdO8LvlOmSvFEaH9ZM/MT xLTxuwDUXBbrMJRNsO4bjrOme2AO1dLYmkZj3OA2oFWrb/i0z1VqZ+zAY Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkAFAO5s91GtJXG8/2dsb2JhbABbgwY1UIJJu0WBHBZ0giYBBAEBATc0CxIBCA4UFDcLJQIEAQ0FCIgIDLkUj00xB4MYbwOZCJAjgVuBOYIq
X-IronPort-AV: E=Sophos;i="4.89,776,1367971200"; d="scan'208";a="238157438"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jul 2013 07:38:21 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6U7cLjD018405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 07:38:21 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 02:38:21 -0500
From: "Shwetha Bhandari (shwethab)" 
To: Paul Ebersman , "Bernie Volz (volz)" 
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
Thread-Index: AQHOjPfDyoywVT1z2kuotyDXFZrDhw==
Date: Tue, 30 Jul 2013 07:38:20 +0000
Message-ID: 
In-Reply-To: <20130729143738.C761026DBDC6@fafnir.remote.dragon.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.0.0.100825
x-originating-ip: [10.61.216.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E8CDFE0D206A74CAC2559CB342A8CCD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-failover-design-03 - Respond by August 9, 2013!
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, 30 Jul 2013 07:38:27 -0000

I have read this draft in reasonable detail and support it going forward.
Thanks to Tomek and Kim for a well thought through draft.

Thanks,
Shwetha

On 7/29/13 4:37 PM, "Paul Ebersman"  wrote:

>
>volz> Folks, the authors of draft-ietf-dhc-dhcpv6-failover-design-03
>volz>=20
>([[http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design]])
>volz> believe it is ready for working group last call. Please review
>volz> this draft and indicate whether or not you feel it is ready to be
>volz> published. Your input is important!
>
>I have read this document and support it going forward.
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From internet-drafts@ietf.org  Tue Jul 30 02:02:09 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 7277121F9C33; Tue, 30 Jul 2013 02:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.529
X-Spam-Level: 
X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETIb6LQ8TTet; Tue, 30 Jul 2013 02:02:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9121F9B40; Tue, 30 Jul 2013 02:00:56 -0700 (PDT)
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.60p1
Message-ID: <20130730090056.19955.84019.idtracker@ietfa.amsl.com>
Date: Tue, 30 Jul 2013 02:00:56 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-13.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, 30 Jul 2013 09:02:10 -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           : Guidelines for Creating New DHCPv6 Options
	Author(s)       : David W. Hankins
                          Tomek Mrugalski
                          Marcin Siodelski
                          Sheng Jiang
                          Suresh Krishnan
	Filename        : draft-ietf-dhc-option-guidelines-13.txt
	Pages           : 29
	Date            : 2013-07-30

Abstract:
   This document provides guidance to prospective DHCPv6 Option
   developers to help them creating option formats that are easily
   adoptable by existing DHCPv6 software.  This document updates
   RFC3315.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-option-guidelines-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From tomasz.mrugalski@gmail.com  Tue Jul 30 02:17: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 80A7A21E80F9 for ; Tue, 30 Jul 2013 02:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XSH-6K6R6AW for ; Tue, 30 Jul 2013 02:17:18 -0700 (PDT)
Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EE75621E80FA for ; Tue, 30 Jul 2013 02:13:36 -0700 (PDT)
Received: by mail-pb0-f48.google.com with SMTP id ma3so2161808pbc.7 for ; Tue, 30 Jul 2013 02:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=m7bAnQVc8sTHIX9GbO6gDKhpVKCoVOjQz+Vh5of8WxA=; b=mEGFmSJ+tRm86DChyQA2FKR/cl4illwhwg81mPl8D9lDC1LlxITR06W34ynChejV7C pmLKGw+Zr8DNtmmBXjKE5Giw7MDs9uiTfTmyXQ38jCcdi2tEUpdvtJVuwflo+PmJSf4V BC1l6HiBOqmCJsWd2uLLg/ApNIoggqwLSeMd0M0UnvEEduf40YtEedYW4+KfgWZ4UqP6 mGBTAM8ryP+1qA+yFvZI56vCCdQbZAn//qMdW/2I6qAg6MLtk5emjcu2xAnGqdsAHPOR lI6pDkajAMT7ScAvGo9iJGl2pAyxcLW3EiS5NAZcHjXNZWkyIk2DI4YvW35WlBHEc5gI nwLg==
X-Received: by 10.68.223.225 with SMTP id qx1mr72087307pbc.157.1375175611458;  Tue, 30 Jul 2013 02:13:31 -0700 (PDT)
Received: from dhcp-108b.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id 7sm25802042paf.22.2013.07.30.02.13.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 02:13:30 -0700 (PDT)
Message-ID: <51F783B7.1000203@gmail.com>
Date: Tue, 30 Jul 2013 11:13:27 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <20130730090056.19955.84019.idtracker@ietfa.amsl.com>
In-Reply-To: <20130730090056.19955.84019.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-13.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, 30 Jul 2013 09:17:19 -0000

Hi,
Version -13 has been uploaded. Hopefully it addresses the only concern
Ralph raised (defines what the fragment type means - it's basically the
option primitive can can be used to construct more complex options).
There's a new (short) paragraph that explains it.

It passed two WGLCs and addressed all raised issues. According to
authors' knowledge, that concludes the WG phase of this work as it is
ready for shepherding.

Thank you to all who contributed, reviewed, commented on or supported
this work.

Tomek

On 13-07-30 11:00, internet-drafats@ietf.org 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           : Guidelines for Creating New DHCPv6 Options
> 	Author(s)       : David W. Hankins
>                           Tomek Mrugalski
>                           Marcin Siodelski
>                           Sheng Jiang
>                           Suresh Krishnan
> 	Filename        : draft-ietf-dhc-option-guidelines-13.txt
> 	Pages           : 29
> 	Date            : 2013-07-30
> 
> Abstract:
>    This document provides guidance to prospective DHCPv6 Option
>    developers to help them creating option formats that are easily
>    adoptable by existing DHCPv6 software.  This document updates
>    RFC3315.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-13
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-option-guidelines-13
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> 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 alexandru.petrescu@gmail.com  Tue Jul 30 02:17:56 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 0381611E81CC for ; Tue, 30 Jul 2013 02:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.119
X-Spam-Level: 
X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q91RzCKq4TWL for ; Tue, 30 Jul 2013 02:17:50 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 025CA21F925A for ; Tue, 30 Jul 2013 02:14:28 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6U9EQP4010303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Jul 2013 11:14:26 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6U9EQlR012964 for ; Tue, 30 Jul 2013 11:14:26 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.86.23]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6U9EJoJ031737 for ; Tue, 30 Jul 2013 11:14:26 +0200
Message-ID: <51F783EA.90405@gmail.com>
Date: Tue, 30 Jul 2013 11:14:18 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> <4C872C87-9D7E-473C-86CE-F1D7CD7FCCA9@gmail.com> <51546BEF.2000206@gmail.com> <51F6AEAF.3020102@gmail.com> <51F74B4F.40004@trans-nt.com>
In-Reply-To: <51F74B4F.40004@trans-nt.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP
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, 30 Jul 2013 09:17:56 -0000

Le 30/07/2013 07:12, Hiroki Nakano a écrit :
> Thank you for remembering 802.11ai :)
>
> At the last meeting on IEEE802.11WG in Geneva, July, TGai finished
> its internal work for Draft 1.0. According to this draft, 802.11
> will have capability to convey L3 packets by Association
> Request/Response frame. Just in my personal opinion, I think this
> feature will not change so much in the future process of 802.11.
>
> I'm trying to fix experimentally DHCPv4 client/server to support
> RCO. In addition, DHCP client should start when WLAN layer decides
> to connect some BSS and to start an association process, that is,
> when the link-up flag of the interface is still off. Moreover, DHCP
> client has to pass the first packet to WLAN layer by 802.11's MLME
> API defined in TGai. DHCP and WLAN layer need close collaboration
> and possiblly need discussion for implementation.
>
> And, how about IPv6...?

Thanks for the report from IEEE TGai and for the question.

IPv6 still needs both DHCP and SLAAC to realize complete
autoconfiguration for a Mobile Router (address/plen, prefix, default route).

I am interested in these aspects from a vehicular perspective: a vehicle
equipped with a Mobile Router connecting to other vehicles, or to ITS
infrastructure, all with 802.11p.

In 802.11p there is no 802.11 Associate Req/Resp, but there is a need
for IPv6 and fast auto-configuration there as well.

Some layers above 80211 but below IP (WAVE, ETSI ITS) do offer some
messages that could be used to shorten IP autoconfiguration time.

Alex

>
> Regards,
>
> Hiroki Nakano Trans New Technology, Inc. 
>
>
> (13/07/30 3:04), Alexandru Petrescu wrote:
>> Any news about IEEE 802.11ai and DHCP?
>>
>> Has the TGai provided a generic container framework to quickly
>> transfer DHCP messages?
>>
>> Alex
>>
>> Le 28/03/2013 17:12, Alexandru Petrescu a écrit :
>>> Le 26/03/2013 10:09, Jouni Korhonen a écrit :
>>>>
>>>> I find it quite interesting and slightly surprising IEEE is
>>>> working on this. In cellular space (3gpp) we have had about
>>>> equivalent mechanism at the NAS protocol layer from the
>>>> beginning.
>>>
>>> I tend to agree.
>>>
>>> For example, there is this link-layer RANAP protocol.  In this,
>>> the UserEquipment sends a "Activate PDP Context Request" with a
>>> "DNS Server IPv6 Address Request", and receives the IPv6 address
>>> of the DNS Server in a "Activate PDP Context Accept".
>>>
>>> This link-layer messaging is redundant with two other IP
>>> protocols: (1) Router Advertisement sending the DNS IPv6 address
>>> (RFC61606 "IPv6 Router Advertisement Options for DNS
>>> Configuration") _and_ with (2) DHCPv6 configuration options
>>> containing the address of the DNS server.
>>>
>>>> It works but has always been a bit of headache, since multiple
>>>>  ways to do the same thing with loads of optional features on
>>>> different layers caused nasty implementation/deployment
>>>> challenges. I hope IEEE does this better now that they are
>>>> doing it ;)
>>>
>>> I think that _if_ at IETF there were such protocol to realize
>>> this fast configuration in the same way that IEEE needs for
>>> crowded hotspot then one could suggest it to IEEE.
>>>
>>> Alex
>>>
>>>>
>>>> - Jouni
>>>>
>>>>
>>>> On Feb 12, 2013, at 10:25 PM, Hiroki Nakano 
>>>>  wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I'm participating in IEEE 802.11 WG TGai task group which is
>>>>> for FILS (Fast Initiali Link Setup). They are working for
>>>>> speeding up of 802.11 process and trying to provide a new
>>>>> framework for higher layer protocols.
>>>>>
>>>>> I'd like to introduce the overview of prospective 802.11ai
>>>>> specification and discuss usages of DHCP on it with DHC WG
>>>>> people in March. The followings are a brief introduction.
>>>>>
>>>>> TGai supposes Wireless LAN is used in very crowded
>>>>> envirionment such as railway stations in a giant metropolis.
>>>>> TGai also supposes moving hosts through the front of Access
>>>>> Points. In these cases, it is effective to reduce management
>>>>> frames of 802.11, especially frames for probing APs,
>>>>> authentication and association. The current framework takes
>>>>> a few seconds to set up network connectivity before starting
>>>>> to communicate. The target of TGai is under one second.
>>>>>
>>>>> TGai is trying to reduce management frames of 802.11 itself,
>>>>> and in addition provide framework for higher layers such as
>>>>> IP to send and receive packets during 802.11 association
>>>>> process. The currently proposed framework provides "ONE
>>>>> round-trip packet exchange" by piggybacking on 802.11
>>>>> Association Request/Response frames.
>>>>>
>>>>> My interest is how to fit DHCP to this framework. In case of
>>>>>  DHCPv4, this is achieved by using Rapid Commit Option
>>>>> (RFC4039) and making some additional and trivial rules. In
>>>>> case of DHCPv6, we have to use both RA and DHCPv6. In
>>>>> addition, DAD and randomly generated addresses have to be
>>>>> considered. Share your idea, please.
>>>>>
>>>>> 802.11 TGai is still going on and its specification is
>>>>> subject to change, but I'd like to discuss in IETF DHCP
>>>>> issues related to 802.11ai and arrange I-D according to the
>>>>> progress of TGai task group.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hiroki Nakano Trans New Technology, Inc. 
>>>>>
>>>>> _______________________________________________ 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 tomasz.mrugalski@gmail.com  Tue Jul 30 04:01:31 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 A976A11E814F for ; Tue, 30 Jul 2013 04:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level: 
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d56BsxsODNlX for ; Tue, 30 Jul 2013 04:01:31 -0700 (PDT)
Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2D72D11E8115 for ; Tue, 30 Jul 2013 04:01:31 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id wy7so5843499pbc.3 for ; Tue, 30 Jul 2013 04:01:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=II4nprmFMvnArpu7Vgp8FPuCLDYeSeQSQzPIo+liJ0Q=; b=pS9BbZSrplG01ml6tswA0bDiG2FD1mwN2PPtiz3ISqp/hqBnKLqSpvq66YdFfHJ2ql H5mFBBmf3SkbeSoKjPGm0AmROXno+IVZAyA5sqfMU2wdVdcxr+X2iBKpsjLpJHI4tBy/ HA+cbK6PDurADt2B9B4et93DVvBVqTpasSa3ZQg/FROPCfHcDerfTbLVzZb3HX3yft0G zrrFPE9p3n+yuYxjSQ7YGX9BxxsLgelocBjGAXKagMCY6KWMdBvUG/tWo7HVwzpcbvZx f1k8aZ/Et+Ex/TDEqWQeZusqysawARbSViCBZ8cQIDkPSjWxXG+2YimM/dMPG5rZa6qC GNGg==
X-Received: by 10.68.163.165 with SMTP id yj5mr72761204pbb.141.1375182090793;  Tue, 30 Jul 2013 04:01:30 -0700 (PDT)
Received: from dhcp-108b.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id zv11sm26412990pab.3.2013.07.30.04.01.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 04:01:30 -0700 (PDT)
Message-ID: <51F79D07.3060209@gmail.com>
Date: Tue, 30 Jul 2013 13:01:27 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: DHC WG 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] DHCPv6 is 10 years old
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, 30 Jul 2013 11:01:31 -0000

Folks,
It's hard to believe, but DHCPv6 was published exactly 10 years ago!

Here's the original announcement:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg02263.html

Personally I think that's a protocol that withstood the trial of time.
During that time all sorts of extensions and mechanisms were developed
that are based on the base spec, yet very few corrections and updates.
There are tons of various implementations - hardware, software, open
source, commercial, from embedded miniatures that are only 23KB in size
to huge enterprise grade provisioning solutions handling millions of
devices, from hobby projects to huge commercial projects will hefty
budgets. That's the real success metric of the protocol.

Let us be the first one to congratulate to all the people who were
involved in the design of this fine protocol - excellent work, guys!

Let the upcoming decades be as successful as the first one.

Bernie & Tomek

From mohta@necom830.hpcl.titech.ac.jp  Tue Jul 30 04:06: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 76E6C11E814F for ; Tue, 30 Jul 2013 04:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDQ44MqMEVN6 for ; Tue, 30 Jul 2013 04:06:53 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 1ED7411E81C4 for ; Tue, 30 Jul 2013 04:06:48 -0700 (PDT)
Received: (qmail 92048 invoked from network); 30 Jul 2013 11:02:56 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 30 Jul 2013 11:02:56 -0000
Message-ID: <51F79E2D.20707@necom830.hpcl.titech.ac.jp>
Date: Tue, 30 Jul 2013 20:06:21 +0900
From: Masataka Ohta 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> <4C872C87-9D7E-473C-86CE-F1D7CD7FCCA9@gmail.com> <51546BEF.2000206@gmail.com> <51F6AEAF.3020102@gmail.com> <51F74B4F.40004@trans-nt.com> <51F783EA.90405@gmail.com>
In-Reply-To: <51F783EA.90405@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP
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, 30 Jul 2013 11:06:58 -0000

Alexandru Petrescu wrote:

> IPv6 still needs both DHCP and SLAAC to realize complete
> autoconfiguration for a Mobile Router (address/plen, prefix, default
> route).

Liaison statements (according to BCP103) from IEEE could resolve
the problem for IETF not admitting DHCP perform full configuration
without RA.

Or, IPv6 won't be efficiently supported by 11ai, which might help
IPv6 fundamentalists recognize the reality that SLAAC, which is
full of states in the worst way to have them distributed, is rather
harmful than useless.

						Masataka Ohta

From leaf.yeh.sdo@gmail.com  Tue Jul 30 04:24: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 3FC2D11E81D7 for ; Tue, 30 Jul 2013 04:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level: 
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.278,  BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk2U9eO2UOre for ; Tue, 30 Jul 2013 04:24:15 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 10C3E11E81EB for ; Tue, 30 Jul 2013 04:24:14 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id p11so2469363pdj.32 for ; Tue, 30 Jul 2013 04:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=I0VvAfMLZuA2FfOFD0s8XGNeoocBuBTv3yu+hWVMI1U=; b=vL8vKuGJ8L/5G+KR3sg5RbudBgKaGiR/fomhOYqb8Hd6dP0USJ+eA5c+6XHPsAz5pN MBBg0B6BU/0GxRZjHV94yeyvt2SBLLIeQTMu0dgAgCAO9oivYgm1Ey2vkueXYLp8f6g/ 4OHs93FpYY4aPUnGgySAr/yTK1Bl7SsKwP8XR7TywuE2tjfz7cOOfaucVTU0D+QuF1XD j3wYoKCTv6xzl54sXZxazwhE6Y25dtaQEjsho/+FG7IqIaOX1dXLYe7F05Tcowti9Ow5 IYpc0O9GWgQvB+lp/C7sP6pe9upsBoJ2mqFqVUhBxuQXY4Ez72g+fI+q+7ptxcsIvh8T 2cXw==
X-Received: by 10.66.194.13 with SMTP id hs13mr41694743pac.163.1375183448486;  Tue, 30 Jul 2013 04:24:08 -0700 (PDT)
Received: from PC ([114.248.234.99]) by mx.google.com with ESMTPSA id vi8sm82497753pbc.31.2013.07.30.04.24.06 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Jul 2013 04:24:07 -0700 (PDT)
From: "Leaf Yeh" 
To: "'Tomek Mrugalski'" , "'DHC WG'" 
References: <51F79D07.3060209@gmail.com>
In-Reply-To: <51F79D07.3060209@gmail.com>
Date: Tue, 30 Jul 2013 19:23:59 +0800
Message-ID: <51f7a257.48ee440a.1eda.41cb@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6NFCksPJ5TxMhxQUK9FQHYJMIIHAAAqWbQ
Content-Language: zh-cn
Subject: Re: [dhcwg] DHCPv6 is 10 years old
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, 30 Jul 2013 11:24:16 -0000

Admire!

Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Tomek Mrugalski
Sent: Tuesday, July 30, 2013 7:01 PM
To: DHC WG
Subject: [dhcwg] DHCPv6 is 10 years old

Folks,
It's hard to believe, but DHCPv6 was published exactly 10 years ago!

Here's the original announcement:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg02263.html

Personally I think that's a protocol that withstood the trial of time.
During that time all sorts of extensions and mechanisms were developed that
are based on the base spec, yet very few corrections and updates.
There are tons of various implementations - hardware, software, open source,
commercial, from embedded miniatures that are only 23KB in size to huge
enterprise grade provisioning solutions handling millions of devices, from
hobby projects to huge commercial projects will hefty budgets. That's the
real success metric of the protocol.

Let us be the first one to congratulate to all the people who were involved
in the design of this fine protocol - excellent work, guys!

Let the upcoming decades be as successful as the first one.

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


From john_brzozowski@cable.comcast.com  Tue Jul 30 05:27: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 1B89111E81ED for ; Tue, 30 Jul 2013 05:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.572
X-Spam-Level: 
X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHONLUM-NyrU for ; Tue, 30 Jul 2013 05:27:12 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1D72211E81EA for ; Tue, 30 Jul 2013 05:26:39 -0700 (PDT)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.85263628; Tue, 30 Jul 2013 06:25:19 -0600
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Tue, 30 Jul 2013 08:26:34 -0400
From: "Brzozowski, John" 
To: Tomek Mrugalski , DHC WG 
Thread-Topic: [dhcwg] DHCPv6 is 10 years old
Thread-Index: AQHOjSAGOwsznnlYxEu3xoe5HJS0WA==
Date: Tue, 30 Jul 2013 12:26:33 +0000
Message-ID: 
In-Reply-To: <51F79D07.3060209@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [68.87.16.246]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7EC39123B2829D4A99568908DA407B25@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dhcwg] DHCPv6 is 10 years old
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, 30 Jul 2013 12:27:18 -0000

DHCPv6 is the foundation for many IPv6 deployments, we have seen the use
of the same grow significantly over the past 3-5 years!


DHCPv6 has proven to be scalable and production ready from this adopters
point of view, we have indeed come along way.

Today 5% of our customer base, and growing, are actively provisioned and
IPv6 enabled care of DHCPv6.

John
-----Original Message-----
From: Tomasz Mrugalski 
Date: Tuesday, July 30, 2013 1:01 PM
To: dhc WG 
Subject: [dhcwg] DHCPv6 is 10 years old

>Folks,
>It's hard to believe, but DHCPv6 was published exactly 10 years ago!
>
>Here's the original announcement:
>http://www.ietf.org/mail-archive/web/dhcwg/current/msg02263.html
>
>Personally I think that's a protocol that withstood the trial of time.
>During that time all sorts of extensions and mechanisms were developed
>that are based on the base spec, yet very few corrections and updates.
>There are tons of various implementations - hardware, software, open
>source, commercial, from embedded miniatures that are only 23KB in size
>to huge enterprise grade provisioning solutions handling millions of
>devices, from hobby projects to huge commercial projects will hefty
>budgets. That's the real success metric of the protocol.
>
>Let us be the first one to congratulate to all the people who were
>involved in the design of this fine protocol - excellent work, guys!
>
>Let the upcoming decades be as successful as the first one.
>
>Bernie & Tomek
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From volz@cisco.com  Wed Jul 31 02:24: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 2718A21F99DC for ; Wed, 31 Jul 2013 02:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGLt1pUdCodZ for ; Wed, 31 Jul 2013 02:24:36 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 70DF021F9B53 for ; Wed, 31 Jul 2013 02:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13202; q=dns/txt; s=iport; t=1375262549; x=1376472149; h=from:to:subject:date:message-id:mime-version; bh=dU/Mk6sgST/+NZXhGPB7HfC21GuITs0CwkaC2i0jVcQ=; b=Y2WEYWMl05SNtaUZ++F8TMYGtRC+kW/gpUZIEvG9uiR0GNWAJFeHmv4N Y0hZXYse/odkL36TxdzBGJHfiDhUx2XcctMzl/sv6YOBr+B7ryd4axHQ/ eIASKBNaRCqZzylTC8MppqUx7KpqHmf8o7JCwwcC71FMiDOHhxuELbWuF c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFAAfX+FGtJV2a/2dsb2JhbABbgkJENVC+HIEXFnSCJgEELV4BKlYmAQQbDId8mAegUI9Ng1BxA6krgxSCKg
X-IronPort-AV: E=Sophos;i="4.89,786,1367971200";  d="scan'208,217";a="241486641"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 31 Jul 2013 09:22:19 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6V9MJbs006027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Jul 2013 09:22:19 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 04:22:19 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: DHC WG Recharter - Thu 9:00-11:30
Thread-Index: Ac6NzueCYI4LOaIpSyKAgSQd1bcd6w==
Date: Wed, 31 Jul 2013 09:22:18 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E18620B61@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.86.252.154]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18620B61xmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] DHC WG Recharter - Thu 9:00-11:30
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, 31 Jul 2013 09:24:48 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E18620B61xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At Thursday's DHC WG session, please be prepared to discuss the re-charter.=
 The text is below.

Proposed DHC WG Charter:

  The Dynamic Host Configuration working group (DHC WG) has developed
  DHCP for automated allocation, configuration and management of IP
  addresses and TCP/IP protocol stack parameters. DHCPv4 is currently
  a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6
  is currently a Proposed Standard and is documented in RFC 3315.
  Subsequent RFCs document additional options and other enhancements to
  the specifications.

  The DHC WG is responsible for defining DHCP protocol extensions.
  Definitions of new DHCP options that are delivered using standard
  mechanisms with documented semantics are not considered a protocol
  extension and thus are outside of scope for DHC WG. Such options should
  be defined within their respective WGs and reviewed by the DHCP
  Directorate. However, if such options require protocol extensions or new
  semantics, the protocol extension work must be done in the DHC WG.

  The DHC WG has the following main objectives:

  * Develop extensions to the DHCPv6 infrastructure as required to meet
  new applications and deployments of DHCP. The topics currently
  in development are:

  - DHCPv6 Failover, High Availability and Load Balancing
  - DNS Update strategies for delegated prefixes (draft-ietf-dhc-dns-pd)
  - Extend DHCPv6 to work with multiple provisioning domains
  - DHCP provisioning of IPv4 clients over IPv6 networks
  - SOLMAXRT counter update
  - Container option
  - Access Network Identifier (draft-ietf-dhc-access-network-identifier)
  - New NTP option to replace OPTION_NTP_SERVER (RFC 5908)
  - Prefix coloring (draft-bhandari-dhc-class-based-prefix)

    Additional topics may only be added with approval from the responsible
    Area Director or by re-chartering.

  * Specify guidelines for creating new DHCPv6 options.

  * Develop documents that help explain operational considerations for
    the wider community.

  * Advance DHCPv6 (RFC 3315) along the IETF Standards Track. This will
  include writing analyses, corrections, and clarifications of the DHCPv6
  specifications, including RFC 3315, RFC3633, RFC3736 and other RFCs
  defining additional options, which identifies and resolves ambiguities,
  contradictory specifications and other obstacles to development of
  interoperable implementations.

END



--_000_489D13FBFA9B3E41812EA89F188F018E18620B61xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











At Thursday’s DHC WG session, please be prepar=
ed to discuss the re-charter. The text is below.


 


Proposed DHC WG Charter:


 


  The Dynamic Host Configuration working group (DHC W=
G) has developed


  DHCP for automated allocation, configuration and ma=
nagement of IP


  addresses and TCP/IP protocol stack parameters. DHC=
Pv4 is currently


  a Draft Standard and is documented in RFC 2131 and =
RFC 2132. DHCPv6


  is currently a Proposed Standard and is documented =
in RFC 3315.


  Subsequent RFCs document additional options and oth=
er enhancements to


  the specifications.


 


  The DHC WG is responsible for defining DHCP protoco=
l extensions.


  Definitions of new DHCP options that are delivered =
using standard


  mechanisms with documented semantics are not consid=
ered a protocol


  extension and thus are outside of scope for DHC WG.=
 Such options should


  be defined within their respective WGs and reviewed=
 by the DHCP


  Directorate. However, if such options require proto=
col extensions or new


  semantics, the protocol extension work must be done=
 in the DHC WG.


 


  The DHC WG has the following main objectives:<=
/o:p>


  



  * Develop extensions to the DHCPv6 infrastruct=
ure as required to meet


  new applications and deployments of DHCP. The topic=
s currently



  in development are:


  



  - DHCPv6 Failover, High Availability and Load =
Balancing


  - DNS Update strategies for delegated prefixes (dra=
ft-ietf-dhc-dns-pd)


  - Extend DHCPv6 to work with multiple provisioning =
domains


  - DHCP provisioning of IPv4 clients over IPv6 netwo=
rks


  - SOLMAXRT counter update


  - Container option



  - Access Network Identifier (draft-ietf-dhc-ac=
cess-network-identifier)


  - New NTP option to replace OPTION_NTP_SERVER (RFC =
5908)


  - Prefix coloring (draft-bhandari-dhc-class-based-p=
refix)


 


    Additional topics may only be added wit=
h approval from the responsible


    Area Director or by re-chartering.=



 


  * Specify guidelines for creating new DHCPv6 option=
s.


 


  * Develop documents that help explain operational c=
onsiderations for


    the wider community.<=
/p>

 


  * Advance DHCPv6 (RFC 3315) along the IETF Standard=
s Track. This will


  include writing analyses, corrections, and clarific=
ations of the DHCPv6


  specifications, including RFC 3315, RFC3633, RFC373=
6 and other RFCs


  defining additional options, which identifies and r=
esolves ambiguities,


  contradictory specifications and other obstacles to=
 development of


  interoperable implementations.

 


END


 


 






--_000_489D13FBFA9B3E41812EA89F188F018E18620B61xmbrcdx04ciscoc_--

From volz@cisco.com  Wed Jul 31 02:26:06 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 0672C21F9EAC for ; Wed, 31 Jul 2013 02:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJDRFma9x0rk for ; Wed, 31 Jul 2013 02:25:46 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 335CA21F99D0 for ; Wed, 31 Jul 2013 02:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26825; q=dns/txt; s=iport; t=1375262724; x=1376472324; h=from:to:subject:date:message-id:mime-version; bh=9+sLp2tIrCmRAuenkU/5hU8Ju7eXoqQeghvFdLvhXEE=; b=SqiTL6ib5GWZ0mo4A99PSSYoxOHxO7GPkL2epzcpBGJQNl116YnH9Y2M sPEAIUHrkcVLjjlimO70mvz4O2tpsp5gH9gCiyiMcoNG/duC+CmqHICPX armfJ5FZDkeegssTNnkWisk8VLgJj6hqhXO6dFS9kARZ6+wz3+jqmXyGH A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAAfX+FGtJXG+/2dsb2JhbABbgkJENVC+HIEXFnSCJgEELT4CHgEqFkAmAQQbDId8mAegUI42CgGBDINQcQOUCJUjgxSBaAEIFyI
X-IronPort-AV: E=Sophos;i="4.89,786,1367971200";  d="scan'208,217";a="241487598"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 31 Jul 2013 09:25:11 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6V9PAKg024805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Jul 2013 09:25:10 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 04:25:10 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: DHC WG DHCP Directorate - Thu 9:00-11:30
Thread-Index: Ac6Nz7ovIHCudntcRGqylEDKksdoDw==
Date: Wed, 31 Jul 2013 09:25:09 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E18620C2C@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.86.252.154]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18620C2Cxmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] DHC WG DHCP Directorate - Thu 9:00-11:30
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, 31 Jul 2013 09:26:07 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E18620C2Cxmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At Thursday's DHC WG meeting please be prepared to discuss the DHCP Directo=
rate. The proposed text is below:

DHCP Directorate

The DHCP Directorate is an advisory group of DHCP experts selected by the
Internet Area Directors.

The notion of a directorate is defined in RFC 2418 as follows:

  In many areas, the Area Directors have formed an advisory group or
  directorate. These comprise experienced members of the IETF and the
  technical community represented by the area. The specific name and the
  details of the role for each group differ from area to area, but the
  primary intent is that these groups assist the Area Director(s), e.g.,
  with the review of specifications produced in the area.


What Does the Directorate Do?

The main purpose of the DHCP Directorate is to review all documents
submitted to the IESG for publication that define new DHCP (DHCPv6 or
DHCPv4) options, DHCP messages, or DHCP client, relay agent or server
processing. Generally speaking, documents advanced by the DHC WG will
have already received review from members of the DHCP Directorate and
thus may not require such review.

While the DHC WG is active, the DHCP Directorate is responsible for
reviewing DHCP options or other extensions (for both IPv4 and IPv6). The
Directorate is expected to review all proposed extensions to DHCP to
ensure that they are consistent with the DHCP specification and other
option formats, that they do not duplicate existing mechanisms, etc.
Generally speaking, the Directorate will not be responsible for evaluating
the semantic content of proposed options.

The tasks performed by the Directorate are:

1. Review all documents submitted to the IESG for publication that have
   DHCP options, messages, or processing requirements. A review is
   triggered:

   - By request for early review (by any AD or by any WG chair)
   - By a document moving to 'publication requested' state
   - By entry on the IESG agenda (for other documents)

2. Assist ADs with judgment issues when requested - The ADs may send email
   to the directorate list when they have issues that they want help with.
   Examples for judgment issues are:

   - New option formats.
   - New client, relay, server agent processing.

3. Try to follow IETF documents related to DHCP as early as possible and
   provide guidance to authors as early as possible.


How is Document Review Organized?

1. The DHCP Directorate Coordinator assigns each document that is
   triggered for review to at least two (2) reviewers and issues a Review
   Request. Authors and contributors to a document must not be assigned.
   The Review Request will include the document and review deadline.
2. The assigned reviewers must acknowledge and agree to review the
   document within 72 hours and respond with a "can review by deadline" or
   "can't review". No reply is interpreted as "can't review".
3. If the Coordinator does not receive "can review by deadline" within 72
   hours, the Coordinator selects at least one or two additional reviewers.
   This process is repeated until at least two reviewers are found.
4. The reviewers provide comments as appropriate (IETF Last Call, Area
   Director, document authors).
5. The Coordinator may decide to call upon additional reviewers if
   expected review is overdue or the topic under review is a complex one.


How is the Directorate Formed?

1.  Directorate members are assigned to the Directorate by the Internet
    Area Directors.
2.  There is an expectation that Directorate membership will not be
    limited to 'old-time DHCP gods from years past'. It is assumed that
    the Directorate will include younger and newer participants who are
    interested in 'learning while doing work'.
3.  Each assignment is for a three year term, unless the member or Internet
    Area Director requests a shorter term.
4.  The terms are staggered so that approximately 1/3 of the directorate
    members have their term end each year.
5.  When the Directorate is first established members of the Directorate
    will be assigned either one year, two years, or three years in their
    first term.
6.  When a member's term expires, the Internet ADs may replace the person
    whose term expires, may reappoint the same person, or may reduce the
    size of the Directorate. There is no expectation that the same person
    will either want to be returned, or will be returned.
7.  The three year term serves as the limit of the commitment of a
    Directorate member, but also serves as a way to return Directorate
    members to the community.
8.  In deciding whether to reappoint a member whose term has expired, the
    Internet ADs may consider the quantity of work that they have done,
    the ADs' impression of the quality of the work, and the comments from
    the authors and other Directorate members regarding the reviews.
9.  If a member resigns before the member's term expires, the Internet
    Area Directors may appoint a replacement.
10. The Internet Area Directors may remove a member before the member's
    term expires, and may appoint a replacement.
11. Internet ADs can assign additional members to the Directorate whenever
    they want to, subject to willingness of people to serve.
12. Both ADs need to agree in order to assign a member to the Directorate.
13. Both ADs select one of the Directorate members as the DHCP Directorate
    Coordinator on a yearly basis.

END



--_000_489D13FBFA9B3E41812EA89F188F018E18620C2Cxmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











At Thursday’s DHC WG meeting please be prepare=
d to discuss the DHCP Directorate. The proposed text is below:

 


DHCP Directorate


 


The DHCP Directorate is an advisory group of DHCP experts =
selected by the


Internet Area Directors.


 


The notion of a directorate is defined in RFC 2418 as foll=
ows:


 


  In many areas, the Area Directors have formed an ad=
visory group or


  directorate. These comprise experienced members of =
the IETF and the


  technical community represented by the area. The sp=
ecific name and the


  details of the role for each group differ from area=
 to area, but the


  primary intent is that these groups assist the Area=
 Director(s), e.g.,


  with the review of specifications produced in the a=
rea.


 


 


What Does the Directorate Do?


 


The main purpose of the DHCP Directorate is to review all =
documents


submitted to the IESG for publication that define new DHCP=
 (DHCPv6 or



DHCPv4) options, DHCP messages, or DHCP client, relay agen=
t or server


processing. Generally speaking, documents advanced by the =
DHC WG will


have already received review from members of the DHCP Dire=
ctorate and


thus may not require such review.


 


While the DHC WG is active, the DHCP Directorate is respon=
sible for


reviewing DHCP options or other extensions (for both IPv4 =
and IPv6). The


Directorate is expected to review all proposed extensions =
to DHCP to


ensure that they are consistent with the DHCP specificatio=
n and other


option formats, that they do not duplicate existing mechan=
isms, etc.


Generally speaking, the Directorate will not be responsibl=
e for evaluating


the semantic content of proposed options.


 


The tasks performed by the Directorate are:


 


1. Review all documents submitted to the IESG for publicat=
ion that have


   DHCP options, messages, or processing require=
ments. A review is


   triggered:


 


   - By request for early review (by any AD or b=
y any WG chair)


   - By a document moving to 'publication reques=
ted' state


   - By entry on the IESG agenda (for other docu=
ments)


 


2. Assist ADs with judgment issues when requested - The AD=
s may send email


   to the directorate list when they have issues=
 that they want help with.


   Examples for judgment issues are:<=
/span>


 


   - New option formats.


   - New client, relay, server agent processing.=



 


3. Try to follow IETF documents related to DHCP as early a=
s possible and


   provide guidance to authors as early as possi=
ble.


 


 


How is Document Review Organized?


 


1. The DHCP Directorate Coordinator assigns each document =
that is


   triggered for review to at least two (2) revi=
ewers and issues a Review


   Request. Authors and contributors to a docume=
nt must not be assigned.


   The Review Request will include the document =
and review deadline.


2. The assigned reviewers must acknowledge and agree to re=
view the


   document within 72 hours and respond with a &=
quot;can review by deadline" or


   "can't review". No reply is interpr=
eted as "can't review".


3. If the Coordinator does not receive "can review by=
 deadline" within 72


   hours, the Coordinator selects at least one o=
r two additional reviewers.


   This process is repeated until at least two r=
eviewers are found.


4. The reviewers provide comments as appropriate (IETF Las=
t Call, Area


   Director, document authors).


5. The Coordinator may decide to call upon additional revi=
ewers if


   expected review is overdue or the topic under=
 review is a complex one.


 


 


How is the Directorate Formed?


 


1.  Directorate members are assigned to the Directora=
te by the Internet


    Area Directors.


2.  There is an expectation that Directorate membersh=
ip will not be


    limited to 'old-time DHCP gods from yea=
rs past'. It is assumed that


    the Directorate will include younger an=
d newer participants who are


    interested in 'learning while doing wor=
k'.


3.  Each assignment is for a three year term, unless =
the member or Internet


    Area Director requests a shorter term.<=
o:p>


4.  The terms are staggered so that approximately 1/3=
 of the directorate


    members have their term end each year.<=
o:p>


5.  When the Directorate is first established members=
 of the Directorate


    will be assigned either one year, two y=
ears, or three years in their


    first term.


6.  When a member's term expires, the Internet ADs ma=
y replace the person


    whose term expires, may reappoint the s=
ame person, or may reduce the


    size of the Directorate. There is no ex=
pectation that the same person


    will either want to be returned, or wil=
l be returned.


7.  The three year term serves as the limit of the co=
mmitment of a


    Directorate member, but also serves as =
a way to return Directorate


    members to the community.


8.  In deciding whether to reappoint a member whose t=
erm has expired, the


    Internet ADs may consider the quantity =
of work that they have done,


    the ADs' impression of the quality of t=
he work, and the comments from


    the authors and other Directorate membe=
rs regarding the reviews.


9.  If a member resigns before the member's term expi=
res, the Internet


    Area Directors may appoint a replacemen=
t.


10. The Internet Area Directors may remove a member before=
 the member's


    term expires, and may appoint a replace=
ment.


11. Internet ADs can assign additional members to the Dire=
ctorate whenever


    they want to, subject to willingness of=
 people to serve.


12. Both ADs need to agree in order to assign a member to =
the Directorate.


13. Both ADs select one of the Directorate members as the =
DHCP Directorate


    Coordinator on a yearly basis.


 


END


 


 






--_000_489D13FBFA9B3E41812EA89F188F018E18620C2Cxmbrcdx04ciscoc_--