From leaf.y.yeh@huawei.com Tue Aug 2 08:12:30 2011 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 CB1FC21F8783 for ; Tue, 2 Aug 2011 08:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=2.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osUZwPjaYQR9 for ; Tue, 2 Aug 2011 08:12:30 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CC9BE21F8781 for ; Tue, 2 Aug 2011 08:12:29 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPB009Q23K4YV@szxga04-in.huawei.com> for dhcwg@ietf.org; Tue, 02 Aug 2011 23:12:05 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPB00MQ03K4IG@szxga04-in.huawei.com> for dhcwg@ietf.org; Tue, 02 Aug 2011 23:12:04 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACV68419; Tue, 02 Aug 2011 23:12:04 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 02 Aug 2011 23:12:01 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.250]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Tue, 02 Aug 2011 23:12:04 +0800 Date: Tue, 02 Aug 2011 15:12:03 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [172.24.2.40] To: "rfc-editor@rfc-editor.org" Message-id: <8E3009A8-895A-444D-B6D9-0C593A57F774@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LZLL/5A8ygdVTjF5r6nzmg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] Correction Item - Errata of RFC3633 ? Thread-index: AcxNaJ1JgwNlSeM/QGSxEKB18VVj3f//fbmA//hJrMD/8EuMkQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <58DFA861-81E1-4735-86A4-33863F012BCC@mimectl> Cc: "dhcwg@ietf.org" , Ole Troan Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ? 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 Aug 2011 15:12:30 -0000 --Boundary_(ID_LZLL/5A8ygdVTjF5r6nzmg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear editors, The author of RFC3633 (Mr. Ole Troan) and I believe that we need do a fix on Errata ID: 2468 at the web page (http://www.rfc-editor.org/errata_search.php?rfc=3633 ). The correct 'Notes' of Errata ID: 2468 shall be 'This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).' Could you instruct us how to make this correction? Best Regards, Leaf -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Friday, July 29, 2011 5:09 AM To: Leaf yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ? Leaf, > I might get a correction item for the Errata of RFC3633 this morning. > > http://www.rfc-editor.org/errata_search.php?rfc=3633 - Errata ID: 2468 > > New last paragraph of 12.2: > When the DR delegates prefixes to a Requesting Router, the > Requesting Router has sole authority for assignment of those > prefixes, and the Delegating Router MUST NOT assign any prefixes > from that delegated prefix to any of its own links. > > Notes: > This change clarifies that the authority over the address space is delegated to the RR. Moving the use restriction for the address space from the RR to the DR. > > I think the correct Notes might be '.... Moving the use restriction for the address space from the DR to the RR.' absolutely. the text is correct though. don't know if notes can be updated in the tool? cheers, Ole --Boundary_(ID_LZLL/5A8ygdVTjF5r6nzmg) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT 
Dear editors,

The author of RFC3633 (Mr. Ole Troan) and I believe that we need do a fix on Errata ID: 2468 at the web page (http://www.rfc-editor.org/errata_search.php?rfc=3633 ).

The correct 'Notes' of Errata ID: 2468 shall be 'This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).'

Could you instruct us how to make this correction?
Best Regards,
Leaf



-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com] 
Sent: Friday, July 29, 2011 5:09 AM
To: Leaf yeh
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ?

Leaf,

> I might get a correction item for the Errata of RFC3633 this morning. 
> 
> http://www.rfc-editor.org/errata_search.php?rfc=3633 - Errata ID: 2468
> 
>  New last paragraph of 12.2:
>  When the DR delegates prefixes to a Requesting Router, the
>  Requesting Router has sole authority for assignment of those
>  prefixes, and the Delegating Router MUST NOT assign any prefixes
>  from that delegated prefix to any of its own links.
> 
>  Notes:
>  This change clarifies that the authority over the address space is delegated to the RR. Moving the use restriction for the address space from the RR to the DR. 
> 
> I think the correct Notes might be '.... Moving the use restriction for the address space from the DR to the RR.'

absolutely.
the text is correct though. don't know if notes can be updated in the tool?

cheers,
Ole
--Boundary_(ID_LZLL/5A8ygdVTjF5r6nzmg)-- From jiangsheng@huawei.com Tue Aug 2 20:17:56 2011 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 7363011E80F7 for ; Tue, 2 Aug 2011 20:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02JGf-wnGBiY for ; Tue, 2 Aug 2011 20:17:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A6CEE11E8081 for ; Tue, 2 Aug 2011 20:17:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPC00NS01570E@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 03 Aug 2011 11:17:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPC00B5N154LJ@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 03 Aug 2011 11:17:31 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACV99356; Wed, 03 Aug 2011 11:17:31 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 03 Aug 2011 11:17:26 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Wed, 03 Aug 2011 11:17:31 +0800 Date: Wed, 03 Aug 2011 03:17:30 +0000 From: Jiangsheng X-Originating-IP: [10.110.98.152] To: "dhcwg@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Is address rejection function needed in address registration? Thread-index: AcxRi960lrgFMw+xRgiOtiEi1JKp8g== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: F+/r HEHE JpqT Kawy MKIL MZVZ N6y7 ODfT PpPK QLc4 SbEN TpKu T5Ud UACs W7t3 XFxk; 2; YwBoAGUAbgBnAGEAbgBnAEAAYwBoAGkAbgBhAG0AbwBiAGkAbABlAC4AYwBvAG0AOwBkAGgAYwB3AGcAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A1BEE1E6-700E-4BAC-9F9C-54F18F187B7D}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 03 Aug 2011 03:17:26 GMT; SQBzACAAYQBkAGQAcgBlAHMAcwAgAHIAZQBqAGUAYwB0AGkAbwBuACAAZgB1AG4AYwB0AGkAbwBuACAAbgBlAGUAZABlAGQAIABpAG4AIABhAGQAZAByAGUAcwBzACAAcgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4APwA= x-cr-puzzleid: {A1BEE1E6-700E-4BAC-9F9C-54F18F187B7D} X-CFilter-Loop: Reflected Cc: ChenGang Subject: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 03:17:56 -0000 Hi, all, In the IETF 81 DHC meeting, we have presented address registration solution. http://tools.ietf.org/html/draft-jiang-dhc-addr-registration-02.txt However, there were debates whether the address registration server should have the ability to reject addresses. So, the authors would like to consult the WG whether this function is needed or not. There are a couple of scenarios authors think it may be useful though they are not strong requirements. A) to refuse the host-generated interface id that does not follow ietf rules, for example RFC 5453 - Reserved IPv6 Interface Identifiers; B) to perform a duplicate address detection. If ND is not deployed or in a point-to-multipoint architecture, the host generated addresses cannot avoid duplication. Then the DHC registration server may play the DAD among the address database. The authors would like to follow the WG consensus whether we keep this address rejection function or not. Best regards, Sheng From Ted.Lemon@nominum.com Wed Aug 3 05:14:40 2011 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 68EEE21F8754 for ; Wed, 3 Aug 2011 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPtf9L6tVoSV for ; Wed, 3 Aug 2011 05:14:40 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id ADFE921F86DD for ; Wed, 3 Aug 2011 05:14:39 -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 DSNKTjk7u2WNtXXNV6c1EhhWZGb+10MRY405@postini.com; Wed, 03 Aug 2011 05:14:51 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 0A7E31B81EE for ; Wed, 3 Aug 2011 05:14:51 -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 DA24A19005D; Wed, 3 Aug 2011 05:14:49 -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.01.0289.001; Wed, 3 Aug 2011 05:14:49 -0700 From: Ted Lemon To: Jiangsheng Thread-Topic: [dhcwg] Is address rejection function needed in address registration? Thread-Index: AcxRi960lrgFMw+xRgiOtiEi1JKp8gAhb70A Date: Wed, 3 Aug 2011 12:14:49 +0000 Message-ID: <116C62CC-BFFF-4486-BD07-92DDDED15F28@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: text/plain; charset="us-ascii" Content-ID: <77051CA0674D2D4392E5838D986CC9B0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 12:14:40 -0000 On Aug 2, 2011, at 11:17 PM, Jiangsheng wrote: > There are a couple of scenarios authors think it may be useful though the= y are not strong requirements. A) to refuse the host-generated interface id= that does not follow ietf rules, for example RFC 5453 - Reserved IPv6 Inte= rface Identifiers; B) to perform a duplicate address detection. If ND is no= t deployed or in a point-to-multipoint architecture, the host generated add= resses cannot avoid duplication. Then the DHC registration server may play = the DAD among the address database. It would be helpful to understand the scenarios where either ND would not b= e deployed, or there would be a point-to-multipoint architecture that would= work with DHCP. My instinct is to think that this is not a real scenario= , but I assume that you would not mention it if you didn't have something i= n mind. If a device is not following the rules, why would it pay attention to the D= HCP server's indication that its address was unacceptable? From ahagens@amsl.com Tue Aug 2 08:35:07 2011 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 E598A11E807F for ; Tue, 2 Aug 2011 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 037ovrtTraPp for ; Tue, 2 Aug 2011 08:35:07 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 454CC11E807E for ; Tue, 2 Aug 2011 08:35:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 8D1611C380C9; Tue, 2 Aug 2011 08:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB103q9DU66Q; Tue, 2 Aug 2011 08:35:16 -0700 (PDT) Received: from rfc2.home (pool-72-66-107-92.washdc.fios.verizon.net [72.66.107.92]) by c1a.amsl.com (Postfix) with ESMTPSA id B2E421C380C1; Tue, 2 Aug 2011 08:35:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <8E3009A8-895A-444D-B6D9-0C593A57F774@mimectl> Date: Tue, 2 Aug 2011 11:35:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69FCE375-9DAF-41A1-A9BE-941A7DB9A4D3@amsl.com> References: <58DFA861-81E1-4735-86A4-33863F012BCC@mimectl> <8E3009A8-895A-444D-B6D9-0C593A57F774@mimectl> To: Leaf yeh X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 03 Aug 2011 11:17:52 -0700 Cc: dhcwg@ietf.org, rdoms.ietf@gmail.com, RFC Editor , Ole Troan Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ? 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 Aug 2011 15:35:08 -0000 Leaf, The Area Directors have the ability to edit the content of errata or = change their status to Verified, Rejected, Held for Document Update (as = described on http://www.rfc-editor.org/status_type_desc.html). In this case, we have corrected the text of the Notes field as you = requested. Please see: http://www.rfc-editor.org/errata_search.php?eid=3D2468 OLD: This change clarifies that the authority over the address space is = delegated to the RR. Moving the use restriction for the address space = from the RR to the DR. NEW: > This change clarifies that the authority over the address space is = delegated to the RR (Requesting Router). Moving the use restriction for = the address space from the=20 > DR (Delegating Router) to the RR (Requesting Router). Note: The status remains Reported, as its status has not been modified by the = Area Director. The type has been changed from Editorial to Technical as the erratum is = not merely "a spelling, grammar, punctuation, or syntax error that does = not affect the technical meaning". Thank you. RFC Editor/ah On Aug 2, 2011, at 11:12 AM, Leaf yeh wrote: > Dear editors, >=20 > The author of RFC3633 (Mr. Ole Troan) and I believe that we need do a = fix on Errata ID: 2468 at the web page ( > http://www.rfc-editor.org/errata_search.php?rfc=3D3633 > ). >=20 > The correct 'Notes' of Errata ID: 2468 shall be 'This change clarifies = that the authority over the address space is delegated to the RR = (Requesting Router). Moving the use restriction for the address space = from the=20 > DR (Delegating Router) to the RR (Requesting Router). > ' >=20 > Could you instruct us how to make this correction? >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:ot@cisco.com]=20 > Sent: Friday, July 29, 2011 5:09 AM > To: Leaf yeh > Cc:=20 > dhcwg@ietf.org >=20 > Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ? >=20 > Leaf, >=20 > > I might get a correction item for the Errata of RFC3633 this = morning.=20 > >=20 > >=20 > http://www.rfc-editor.org/errata_search.php?rfc=3D3633 > - Errata ID: 2468 > >=20 > > New last paragraph of 12.2: > > When the DR delegates prefixes to a Requesting Router, the > > Requesting Router has sole authority for assignment of those > > prefixes, and the Delegating Router MUST NOT assign any prefixes > > from that delegated prefix to any of its own links. > >=20 > > Notes: > > This change clarifies that the authority over the address space is = delegated to the RR. Moving the use restriction for the address space = from the RR to the DR.=20 > >=20 > > I think the correct Notes might be '.... Moving the use restriction = for the address space from the DR to the RR.' >=20 > absolutely. > the text is correct though.=20 > don't know if notes can be updated in the tool > ? >=20 > cheers, > Ole >=20 From john_brzozowski@cable.comcast.com Wed Aug 3 22:04:30 2011 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 8208511E80E1 for ; Wed, 3 Aug 2011 22:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=2.364, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRa4NQCXjvK0 for ; Wed, 3 Aug 2011 22:04:29 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53C11E80A6 for ; Wed, 3 Aug 2011 22:04:29 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136161763; Thu, 04 Aug 2011 01:04:33 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 01:04:33 -0400 From: "Brzozowski, John" To: Jiangsheng , dhc WG Thread-Topic: [dhcwg] Is address rejection function needed in address registration? Thread-Index: AQHMUmP/+TRN10DfEkG7OJfvo4dwWg== Date: Thu, 4 Aug 2011 05:04:31 +0000 Message-ID: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 05:04:30 -0000 The server will not need to perform DAD necessarily. If it has assigned the requested address it MUST reject the request for the same from a different client. 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 e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =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 On 8/2/11 11:17 PM, "Jiangsheng" wrote: >Hi, all, > >In the IETF 81 DHC meeting, we have presented address registration >solution.=20 >http://tools.ietf.org/html/draft-jiang-dhc-addr-registration-02.txt > >However, there were debates whether the address registration server >should have the ability to reject addresses. So, the authors would like >to consult the WG whether this function is needed or not. > >There are a couple of scenarios authors think it may be useful though >they are not strong requirements. A) to refuse the host-generated >interface id that does not follow ietf rules, for example RFC 5453 - >Reserved IPv6 Interface Identifiers; B) to perform a duplicate address >detection. If ND is not deployed or in a point-to-multipoint >architecture, the host generated addresses cannot avoid duplication. Then >the DHC registration server may play the DAD among the address database. > >The authors would like to follow the WG consensus whether we keep this >address rejection function or not. > >Best regards, > >Sheng > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From john_brzozowski@cable.comcast.com Wed Aug 3 22:06:57 2011 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 CC01211E80E1 for ; Wed, 3 Aug 2011 22:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=2.364, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ41HTGZih1m for ; Wed, 3 Aug 2011 22:06:57 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 702F711E80A6 for ; Wed, 3 Aug 2011 22:06:57 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.136161770; Thu, 04 Aug 2011 01:04:54 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 01:04:54 -0400 From: "Brzozowski, John" To: Jiangsheng , dhc WG Thread-Topic: [dhcwg] Is address rejection function needed in address registration? Thread-Index: AQHMUmQLlAeeVC+/dUyOfvKKH1qbdQ== Date: Thu, 4 Aug 2011 05:04:52 +0000 Message-ID: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <0432ED89CC8BF44DB88A85C29A9AE87C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 05:06:57 -0000 The server will not need to perform DAD necessarily. If it has assigned the requested address it MUST reject the request for the same from a different client. 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 e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =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 On 8/2/11 11:17 PM, "Jiangsheng" wrote: >Hi, all, > >In the IETF 81 DHC meeting, we have presented address registration >solution.=20 >http://tools.ietf.org/html/draft-jiang-dhc-addr-registration-02.txt > >However, there were debates whether the address registration server >should have the ability to reject addresses. So, the authors would like >to consult the WG whether this function is needed or not. > >There are a couple of scenarios authors think it may be useful though >they are not strong requirements. A) to refuse the host-generated >interface id that does not follow ietf rules, for example RFC 5453 - >Reserved IPv6 Interface Identifiers; B) to perform a duplicate address >detection. If ND is not deployed or in a point-to-multipoint >architecture, the host generated addresses cannot avoid duplication. Then >the DHC registration server may play the DAD among the address database. > >The authors would like to follow the WG consensus whether we keep this >address rejection function or not. > >Best regards, > >Sheng > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Thu Aug 4 02:13:10 2011 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 54F6921F8B50 for ; Thu, 4 Aug 2011 02:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl-YXDhClRax for ; Thu, 4 Aug 2011 02:13:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A6E4F21F8B38 for ; Thu, 4 Aug 2011 02:13:09 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE00HH1C8T1M@szxga05-in.huawei.com> for dhcwg@ietf.org; Thu, 04 Aug 2011 17:12:29 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE000N9C7ZML@szxga05-in.huawei.com> for dhcwg@ietf.org; Thu, 04 Aug 2011 17:12:29 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADA11316; Thu, 04 Aug 2011 17:12:27 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 04 Aug 2011 17:12:23 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Thu, 04 Aug 2011 17:12:27 +0800 Date: Thu, 04 Aug 2011 09:12:26 +0000 From: Jiangsheng In-reply-to: <116C62CC-BFFF-4486-BD07-92DDDED15F28@nominum.com> X-Originating-IP: [10.110.98.152] To: Ted Lemon Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201225FD8@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Is address rejection function needed in address registration? Thread-index: AQHMUdb79UlszbrwTkqSaZE6Vm3rlJUMBfEQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> <116C62CC-BFFF-4486-BD07-92DDDED15F28@nominum.com> Cc: "dhcwg@ietf.org" , ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 09:13:10 -0000 > On Aug 2, 2011, at 11:17 PM, Jiangsheng wrote: > > There are a couple of scenarios authors think it may be useful though > they are not strong requirements. A) to refuse the host-generated > interface id that does not follow ietf rules, for example RFC 5453 - > Reserved IPv6 Interface Identifiers; B) to perform a duplicate address > detection. If ND is not deployed or in a point-to-multipoint > architecture, the host generated addresses cannot avoid duplication. > Then the DHC registration server may play the DAD among the address > database. > > It would be helpful to understand the scenarios where either ND would > not be deployed, or there would be a point-to-multipoint architecture > that would work with DHCP. My instinct is to think that this is not a > real scenario, but I assume that you would not mention it if you didn't > have something in mind. > > If a device is not following the rules, why would it pay attention to > the DHCP server's indication that its address was unacceptable? draft-ietf-6man-dad-proxy in 6man wg has described the point-to-multipoint architecture, in which ND DAD cannot guarantee address collision free. DAD proxy can be one of the solution, so our registration function. Sheng From jiangsheng@huawei.com Thu Aug 4 02:19:30 2011 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 EE2FE21F8B56 for ; Thu, 4 Aug 2011 02:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XowR9btZaAZ0 for ; Thu, 4 Aug 2011 02:19:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7421F8B24 for ; Thu, 4 Aug 2011 02:19:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE00LQ7CJRGL@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 04 Aug 2011 17:19:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE000VBCJRMV@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 04 Aug 2011 17:19:03 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACX26265; Thu, 04 Aug 2011 17:19:02 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 04 Aug 2011 17:18:56 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Thu, 04 Aug 2011 17:19:01 +0800 Date: Thu, 04 Aug 2011 09:19:01 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.152] To: "Brzozowski, John" , dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201226008@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Is address rejection function needed in address registration? Thread-index: AcxRi960lrgFMw+xRgiOtiEi1JKp8gAlRGKAAAjjbtA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> Cc: ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 09:19:31 -0000 > The server will not need to perform DAD necessarily. If it has > assigned > the requested address it MUST reject the request for the same from a > different client. Yes, DHCPv6 server does not need to perform DAD, instead, it only checks through its address database. The debate point here is whether the address collision scenario exists. If it exists, we need the rejection function; otherwise, the DHCPv6 may have only registration function. Sheng > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski@cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 8/2/11 11:17 PM, "Jiangsheng" wrote: > > >Hi, all, > > > >In the IETF 81 DHC meeting, we have presented address registration > >solution. > >http://tools.ietf.org/html/draft-jiang-dhc-addr-registration-02.txt > > > >However, there were debates whether the address registration server > >should have the ability to reject addresses. So, the authors would > like > >to consult the WG whether this function is needed or not. > > > >There are a couple of scenarios authors think it may be useful though > >they are not strong requirements. A) to refuse the host-generated > >interface id that does not follow ietf rules, for example RFC 5453 - > >Reserved IPv6 Interface Identifiers; B) to perform a duplicate address > >detection. If ND is not deployed or in a point-to-multipoint > >architecture, the host generated addresses cannot avoid duplication. > Then > >the DHC registration server may play the DAD among the address > database. > > > >The authors would like to follow the WG consensus whether we keep this > >address rejection function or not. > > > >Best regards, > > > >Sheng > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Fri Aug 5 04:20:34 2011 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 60D8221F8B2A for ; Fri, 5 Aug 2011 04:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[AWL=2.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL87WFJg-j-N for ; Fri, 5 Aug 2011 04:20:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8621F8B28 for ; Fri, 5 Aug 2011 04:20:32 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPG00KHGCTDPL@szxga03-in.huawei.com> for dhcwg@ietf.org; Fri, 05 Aug 2011 19:20:01 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPG00F7DCTD2E@szxga03-in.huawei.com> for dhcwg@ietf.org; Fri, 05 Aug 2011 19:20:01 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACY24319; Fri, 05 Aug 2011 19:20:00 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 05 Aug 2011 19:19:51 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.250]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Fri, 05 Aug 2011 19:19:59 +0800 Date: Fri, 05 Aug 2011 11:19:58 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.86] To: "dhcwg@ietf.org WG" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UR3Vm2GAqYP9/K/TEh262w)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Quick review on the draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 Thread-index: AcxTYZpHYjPmSJ62Sjuz2Ha9yzX7OA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: Ted Lemon Subject: [dhcwg] Quick review on the draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 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 Aug 2011 11:20:34 -0000 --Boundary_(ID_UR3Vm2GAqYP9/K/TEh262w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SW4gdGhlIERIQyBzZXNzaW9uIG9mIElFVEY4MSwgdGhlIGxhc3Qgc2xpZGUgb2YgREhDIFdHIEFk bWluaXN0cml2aWEgKDAxLWFkbWluaXN0cml2aWE8aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy84MS9zbGlkZXMvZGhjLTExLnBkZj4gLyBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzgxL3NsaWRlcy9kaGMtMTEucGRmICkgY2FsbGVkIGZvciB0aGUgcmV2aWV3IG9yIHN0YXR1 ZSB1cGRhdGUgYWdhaW5zdCBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmVjb25maWd1cmUtcmViaW5k LTA3PGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmVjb25m aWd1cmUtcmViaW5kPi4NCg0KSSByZWFkIHRoaXMgZHJhZnQgdG9kYXksIGJ1dCB3b25kZXIgdGhl IHVzZSBjYXNlIHdoZW4gd2UgbmVlZCBSZWJpbmQgb2YgbXNnLXR5cGUgaW4gdGhlIFJlY29uZmln dXJhdGlvbiBNZXNzYWdlIE9wdGlvbiBpbmNsdWRlZCBpbiB0aGUgc2VydmVyLWluaXRpYXRlZCBS ZWNvbmZpZ3VyYXRpb24gTWVzc2FnZS4NCg0KVGhlIGRlc2NyaXB0aW9uIGdvdCBmcm9tIHRoZSBz ZWN0aW9uIDEgKEludHJvZHVjdGlvbikgb2YgdGhlIGFib3ZlIGRyYWZ0IChkcmFmdC1pZXRmLWRo Yy1kaGNwdjYtcmVjb25maWd1cmUtcmViaW5kLTA3PGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1pZXRmLWRoYy1kaGNwdjYtcmVjb25maWd1cmUtcmViaW5kPikgaXMgYXMgZm9sbG93czoN Cg0K4oCYVW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzLCBpdCBtYXkgYmUgZGVzaXJhYmxlDQogICBm b3IgdGhlIGNsaWVudCB0byBjb21tdW5pY2F0ZSB3aXRoIGEgZGlmZmVyZW50IHNlcnZlcjsgZm9y IGV4YW1wbGUsDQogICBpZiB0aGUgc2VydmVyIHRoYXQgdGhlIGNsaWVudCBtb3N0IHJlY2VudGx5 IGNvbW11bmljYXRlZCB3aXRoIGlzIG5vDQogICBsb25nZXIgYXZhaWxhYmxlLCB0aGUgbmV0d29y ayBhZG1pbmlzdHJhdG9yIG1heSB3YW50IHRoZSBjbGllbnQgdG8NCiAgIGNvbW11bmljYXRlIHdp dGggYSBkaWZmZXJlbnQgc2VydmVyLuKAmQ0KDQpJbiB0aGUgZ2VuZXJhbCB0aGlua2luZywgaWYg dGhlIHNlcnZlciBoYXMgc29tZSBuZXcgKG9yIHVwZGF0ZWQpIGNvbmZpZ3VyYXRpb24gcGFyYW1l dGVyIGZvciB0aGUgY2xpZW50LCB0aGVuIHRoZSBzZXJ2ZXIgaW5pdGlhdGUgYSBjb25maWd1cmF0 aW9uIGV4Y2hhbmdlIHRocm91Z2ggUmVjb25maWd1cmF0aW9uLXJlbmV3L1JlcGx5IG1lc3NhZ2Uu DQoNClNvIHRoZSBxdWVzdGlvbiBpcyB3aHkgdGhlIHNlcnZlciBkZWZpbml0ZWx5IGtub3dzIHRo YXQgaXQgbmVlZCB0byBhc2sgdGhlIGNsaWVudCB0byBnZXQgY29uZmlndXJhdGlvbiBmcm9tIGEg ZGlmZmVyZW50IHNldmVyPw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg== --Boundary_(ID_UR3Vm2GAqYP9/K/TEh262w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IkJvb2sgQW50aXF1YSI7DQoJcGFub3NlLTE6MiA0IDYgMiA1IDMgNSAzIDMgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0 LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNp emU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K LyogUGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQtanVzdGlmeS10 cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Jv b2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SW4gdGhlIERIQyBzZXNzaW9uIG9m IElFVEY4MSwgdGhlIGxhc3Qgc2xpZGUgb2YgREhDIFdHIEFkbWluaXN0cml2aWEgKDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy84MS9zbGlkZXMvZGhjLTExLnBkZiI+MDEtYWRtaW5pc3RyaXZpYTwvYT4NCiAvIDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50 aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvZGhjLTExLnBkZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy84MS9zbGlkZXMvZGhjLTExLnBkZjwvYT4gKSBjYWxsZWQgZm9yIHRoZSByZXZp ZXcgb3Igc3RhdHVlIHVwZGF0ZSBhZ2FpbnN0DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRoYy1kaGNw djYtcmVjb25maWd1cmUtcmViaW5kIj5kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmVjb25maWd1cmUt cmViaW5kLTA3PC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1 YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgcmVhZCB0aGlz IGRyYWZ0IHRvZGF5LCBidXQgd29uZGVyIHRoZSB1c2UgY2FzZSB3aGVuIHdlIG5lZWQgUmViaW5k IG9mIG1zZy10eXBlIGluIHRoZSBSZWNvbmZpZ3VyYXRpb24gTWVzc2FnZSBPcHRpb24gaW5jbHVk ZWQgaW4gdGhlIHNlcnZlci1pbml0aWF0ZWQgUmVjb25maWd1cmF0aW9uIE1lc3NhZ2UuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlx dWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBkZXNjcmlwdGlvbiBnb3QgZnJvbSB0aGUg c2VjdGlvbiAxIChJbnRyb2R1Y3Rpb24pIG9mIHRoZSBhYm92ZSBkcmFmdCAoPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yZWNvbmZpZ3VyZS1y ZWJpbmQiPmRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yZWNvbmZpZ3VyZS1yZWJpbmQtMDc8L2E+KQ0K IGlzIGFzIGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlx dWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0 O3RleHQtaW5kZW50OjE1Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJhVbmRlciBzb21lIGNp cmN1bXN0YW5jZXMsIGl0IG1heSBiZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ZGVzaXJhYmxl PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IGZvciB0aGUgY2xpZW50IHRvIGNvbW11bmljYXRlIHdp dGggYSBkaWZmZXJlbnQgc2VydmVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj47IGZvciBleGFt cGxlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IGlmIHRoZSBzZXJ2ZXIgdGhhdCB0aGUgY2xpZW50IG1vc3QgcmVjZW50bHkgY29tbXVuaWNh dGVkIHdpdGggaXMgbm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyBsb25nZXIgYXZhaWxhYmxlLCB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9y IG1heSB3YW50IHRoZSBjbGllbnQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRlIHdp dGggYSBkaWZmZXJlbnQgc2VydmVyLuKAmTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVh JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JbiB0aGUgZ2VuZXJhbCB0aGlua2luZywgaWYgdGhl IHNlcnZlciBoYXMgc29tZSBuZXcgKG9yIHVwZGF0ZWQpIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVy IGZvciB0aGUgY2xpZW50LCB0aGVuIHRoZSBzZXJ2ZXIgaW5pdGlhdGUgYSBjb25maWd1cmF0aW9u IGV4Y2hhbmdlIHRocm91Z2ggUmVjb25maWd1cmF0aW9uLXJlbmV3L1JlcGx5DQogbWVzc2FnZS4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBB bnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TbyB0aGUgcXVlc3Rpb24gaXMgd2h5IHRo ZSBzZXJ2ZXIgZGVmaW5pdGVseSBrbm93cyB0aGF0IGl0IG5lZWQgdG8gYXNrIHRoZSBjbGllbnQg dG8gZ2V0IGNvbmZpZ3VyYXRpb24gZnJvbSBhIGRpZmZlcmVudCBzZXZlcj88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZXN0IFJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPkxlYWY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_UR3Vm2GAqYP9/K/TEh262w)-- From Ted.Lemon@nominum.com Fri Aug 5 06:25:40 2011 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 A2DFA21F8B8E for ; Fri, 5 Aug 2011 06:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoyJ+j0bwoqz for ; Fri, 5 Aug 2011 06:25:40 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id DC8DD21F8B7C for ; Fri, 5 Aug 2011 06:25:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTjvvZbixhnVBRo6hRWOH3maQ2etY71X2@postini.com; Fri, 05 Aug 2011 06:25:57 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 DB3631B8076 for ; Fri, 5 Aug 2011 06:25:56 -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 D5CE119005D; Fri, 5 Aug 2011 06:25:56 -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.01.0289.001; Fri, 5 Aug 2011 06:25:51 -0700 From: Ted Lemon To: Leaf yeh Thread-Topic: Quick review on the draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 Thread-Index: AcxTYZpHYjPmSJ62Sjuz2Ha9yzX7OAATELGA Date: Fri, 5 Aug 2011 13:25:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_DF20A537AA1A4AD3B659421C80F6149Dnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Quick review on the draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 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 Aug 2011 13:25:40 -0000 --_000_DF20A537AA1A4AD3B659421C80F6149Dnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 5, 2011, at 7:19 AM, Leaf yeh wrote: So the question is why the server definitely knows that it need to ask the = client to get configuration from a different sever? The server doesn't know. The server administrator knows that the original= server is down, and that the client must talk to a different server. --_000_DF20A537AA1A4AD3B659421C80F6149Dnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 5, 2011, at 7:19 AM, Leaf yeh wrote:
So the = question is why the server definitely knows that it need to ask the client = to get configuration from a different sever?

The server doesn't know.   The server administrator knows that th= e original server is down, and that the client must talk to a different ser= ver.

--_000_DF20A537AA1A4AD3B659421C80F6149Dnominumcom_-- From internet-drafts@ietf.org Fri Aug 5 07:36:04 2011 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 7E76421F8C0B; Fri, 5 Aug 2011 07:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaRzK8InFOeU; Fri, 5 Aug 2011 07:36:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F73021F8B01; Fri, 5 Aug 2011 07:36:04 -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: 3.57 Message-ID: <20110805143604.4043.65463.idtracker@ietfa.amsl.com> Date: Fri, 05 Aug 2011 07:36:04 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-pd-exclude-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: Fri, 05 Aug 2011 14:36:04 -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 Gr= oup of the IETF. Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation Author(s) : Jouni Korhonen Teemu Savolainen Suresh Krishnan Ole Troan Filename : draft-ietf-dhc-pd-exclude-03.txt Pages : 10 Date : 2011-08-05 This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. The new mechanism updates RFC 3633. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-03.txt From tomasz.mrugalski@gmail.com Fri Aug 5 10:51:32 2011 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 018AE21F8BBB for ; Fri, 5 Aug 2011 10:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOByyXAxi7Bd for ; Fri, 5 Aug 2011 10:51:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD6221F8BAE for ; Fri, 5 Aug 2011 10:51:31 -0700 (PDT) Received: by wyg8 with SMTP id 8so1498500wyg.31 for ; Fri, 05 Aug 2011 10:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=EZ7pDr+VSToJC9gVY87TRe278mVfNTEATAiojyUWoms=; b=hFkwv5BmTxPMjdfWrJmn51vTormkFr26zLPQKT5n9M0Cmkbk0M/CbH3oeI4rFT9pUj jYO+tfePeb0ze+4KhVxkBTYtL3Iqw4xKUZCIJa3iIOhDgJNd4ieYYF+gKndciYHFVk9s Cqf5hqQ/v8fdZhL2OBFyXIXNujabk+aj7272Y= Received: by 10.216.69.65 with SMTP id m43mr873874wed.4.1312566708716; Fri, 05 Aug 2011 10:51:48 -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 ESMTPS id fr7sm2470990wbb.5.2011.08.05.10.51.46 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 10:51:47 -0700 (PDT) Message-ID: <4E3C2DB2.2050103@gmail.com> Date: Fri, 05 Aug 2011 19:51:46 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dhcwg@ietf.org References: In-Reply-To: X-TagToolbar-Keys: D20110805195146742 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Quick review on the draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 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 Aug 2011 17:51:32 -0000 On 05.08.2011 15:25, Ted Lemon wrote: > On Aug 5, 2011, at 7:19 AM, Leaf yeh wrote: >> So the question is why the server definitely knows that it need to ask >> the client to get configuration from a different sever? > > The server doesn't know. The server administrator knows that the > original server is down, and that the client must talk to a different > server. Another possibility is that such reconfigure event may be part of graceful server shutdown procedure. That would avoid RENEW flood for period between T1 and T2. Clients would immediately REBIND to new server. Oh, and by the way - I read and support this draft. Tomek From jiangsheng@huawei.com Sun Aug 7 23:56:56 2011 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 4606A21F84C8 for ; Sun, 7 Aug 2011 23:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 07pxfiXPeYDG for ; Sun, 7 Aug 2011 23:56:55 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D7AB721F8736 for ; Sun, 7 Aug 2011 23:56:45 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL00J3BKLVS2@szxga05-in.huawei.com> for dhcwg@ietf.org; Mon, 08 Aug 2011 14:56:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL007KFKK4KJ@szxga05-in.huawei.com> for dhcwg@ietf.org; Mon, 08 Aug 2011 14:56:19 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACZ54299; Mon, 08 Aug 2011 14:56:18 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 08 Aug 2011 14:56:16 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Mon, 08 Aug 2011 14:56:12 +0800 Date: Mon, 08 Aug 2011 06:56:10 +0000 From: Jiangsheng In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B9201226008@SZXEML506-MBS.china.huawei.com> X-Originating-IP: [10.110.98.152] To: Jiangsheng , "Brzozowski, John" , dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012285A4@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Is address rejection function needed in address registration? Thread-index: AcxRi960lrgFMw+xRgiOtiEi1JKp8gAlRGKAAAjjbtAA1IqbwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201226008@SZXEML506-MBS.china.huawei.com> Cc: ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 06:56:56 -0000 Now, the only scenario is the requested addresses collision. Is it possible, particularly in the point-to-multipoint network topology? If the scenario is real, we probably need the address rejection function; otherwise, the authors would like to remove it from the address registration procedure. Ted, John, how do you think? Sheng > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Jiangsheng > Sent: Thursday, August 04, 2011 5:19 PM > To: Brzozowski, John; dhc WG > Cc: ChenGang > Subject: Re: [dhcwg] Is address rejection function needed in address > registration? > > > The server will not need to perform DAD necessarily. If it has > > assigned > > the requested address it MUST reject the request for the same from a > > different client. > > Yes, DHCPv6 server does not need to perform DAD, instead, it only > checks through its address database. The debate point here is whether > the address collision scenario exists. If it exists, we need the > rejection function; otherwise, the DHCPv6 may have only registration > function. > > Sheng > > > John > > ========================================= > > John Jason Brzozowski > > Comcast Cable > > e) mailto:john_brzozowski@cable.comcast.com > > o) 609-377-6594 > > m) 484-962-0060 > > w) http://www.comcast6.net > > ========================================= > > > > > > > > > > On 8/2/11 11:17 PM, "Jiangsheng" wrote: > > > > >Hi, all, > > > > > >In the IETF 81 DHC meeting, we have presented address registration > > >solution. > > >http://tools.ietf.org/html/draft-jiang-dhc-addr-registration-02.txt > > > > > >However, there were debates whether the address registration server > > >should have the ability to reject addresses. So, the authors would > > like > > >to consult the WG whether this function is needed or not. > > > > > >There are a couple of scenarios authors think it may be useful > though > > >they are not strong requirements. A) to refuse the host-generated > > >interface id that does not follow ietf rules, for example RFC 5453 - > > >Reserved IPv6 Interface Identifiers; B) to perform a duplicate > address > > >detection. If ND is not deployed or in a point-to-multipoint > > >architecture, the host generated addresses cannot avoid duplication. > > Then > > >the DHC registration server may play the DAD among the address > > database. > > > > > >The authors would like to follow the WG consensus whether we keep > this > > >address rejection function or not. > > > > > >Best regards, > > > > > >Sheng > > > > > > > > >_______________________________________________ > > >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 Ted.Lemon@nominum.com Mon Aug 8 07:52:30 2011 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 A62F521F8B31 for ; Mon, 8 Aug 2011 07:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6E753A45opcz for ; Mon, 8 Aug 2011 07:52:30 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DF37E21F8B22 for ; Mon, 8 Aug 2011 07:52:29 -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 DSNKTj/4R7ZsYUEY9WAQC+usrXG32UrfzEWH@postini.com; Mon, 08 Aug 2011 07:52:56 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 420781B81C0 for ; Mon, 8 Aug 2011 07:52:55 -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 2B7BE190052; Mon, 8 Aug 2011 07:52:50 -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.01.0289.001; Mon, 8 Aug 2011 07:52:43 -0700 From: Ted Lemon To: Jiangsheng Thread-Topic: [dhcwg] Is address rejection function needed in address registration? Thread-Index: AQHMUmQKGGqDDUfKmU+n4fTcjXc0EZUM36iAgAYhagCAAIUmgA== Date: Mon, 8 Aug 2011 14:52:43 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201226008@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B92012285A4@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92012285A4@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_FF0A26E623D34C569F93670FCD52C3CAnominumcom_" MIME-Version: 1.0 Cc: dhc WG , ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 14:52:30 -0000 --_000_FF0A26E623D34C569F93670FCD52C3CAnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 8, 2011, at 2:56 AM, Jiangsheng wrote: Now, the only scenario is the requested addresses collision. Is it possible= , particularly in the point-to-multipoint network topology? If the scenario= is real, we probably need the address rejection function; otherwise, the a= uthors would like to remove it from the address registration procedure. DAD proxy solves this problem, or at least proposes to. So I think if you= don't care to solve this problem, you shouldn't feel obligated to do so. = A lot of resistance to the draft is a mistaken impression that address rej= ection is being used as an address allocation control mechanism, so you are= going to have a much easier time of it if you take out that part. Also, FWIW, I think DAD proxy is a better solution to the problem anyway. --_000_FF0A26E623D34C569F93670FCD52C3CAnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 8, 2011, at 2:56 AM, Jiangsheng wrote:
Now, the only scenario is the requested addresses collision. Is it possible, pa= rticularly in the point-to-multipoint network topology? If the scenario is = real, we probably need the address rejection function; otherwise, the autho= rs would like to remove it from the address registration procedure.

DAD proxy solves this problem, or at least proposes to.   So I th= ink if you don't care to solve this problem, you shouldn't feel obligated t= o do so.   A lot of resistance to the draft is a mistaken impression t= hat address rejection is being used as an address allocation control mechanism, so you are going to have a much easi= er time of it if you take out that part.

Also, FWIW, I think DAD proxy is a better solution to the problem anyw= ay.

--_000_FF0A26E623D34C569F93670FCD52C3CAnominumcom_-- From leaf.y.yeh@huawei.com Mon Aug 8 09:05:30 2011 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 1B93D21F8B19 for ; Mon, 8 Aug 2011 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[AWL=-2.399, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 jrR-bv7CXzgq for ; Mon, 8 Aug 2011 09:05:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8321F8A7E for ; Mon, 8 Aug 2011 09:05:28 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPM00ADBA1SY2@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 09 Aug 2011 00:05:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPM0010PA1RTR@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 09 Aug 2011 00:05:52 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACZ97706; Tue, 09 Aug 2011 00:05:48 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 09 Aug 2011 00:05:46 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.116]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Tue, 09 Aug 2011 00:05:48 +0800 Date: Mon, 08 Aug 2011 16:05:47 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [172.24.2.40] To: "rfc-editor@rfc-editor.org" , "ahagens@amsl.com" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5jMRwKRcLk8CzbrEqGmlGQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] Item for the Errata - Section 17.2.1 - RFC3315? Thread-index: AcxNYrcIg4nOpobdSPi/5s4muLi9hABwgnDQAa9SbqsAAL/fXA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7748265D-39EA-44CD-B94E-00D7CAEEDD29@mimectl> Cc: "dhcwg@ietf.org" , "rdroms.ietf@gmail.com" , "Bernie Volz \(volz\)" Subject: [dhcwg] =?gb2312?b?tPC4tDogIEl0ZW0gZm9yIHRoZSBFcnJhdGEgLSBTZWN0?= =?gb2312?b?aW9uIDE3LjIuMSAtIFJGQzMzMTU/?= 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 Aug 2011 16:05:30 -0000 --Boundary_(ID_5jMRwKRcLk8CzbrEqGmlGQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGksIEFsaWNlDQoNCg0KDQpUaGUgYXV0aG9yIG9mIFJGQzMzMTUgKE1yLiBCZXJuaWUgVm9seikg YW5kIEkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgYSBmaXggaW4gdGhlIHNlY3Rpb24gMTcuMi4xIG9m IFJGQzMzMTUuDQoNCg0KDQpTZWN0aW9uIDE3LjIuMSBzYXlzOg0KDQoNCg0KICAgRm9yIGV4YW1w bGUsIGlmIHRoZSBhZG1pbmlzdHJhdGl2ZSBwb2xpY3kgZm9yIHRoZSBzZXJ2ZXIgaXMNCiAgIHRo YXQgaXQgbWF5IG9ubHkgcmVzcG9uZCB0byBhIGNsaWVudCB0aGF0IGlzIHdpbGxpbmcgdG8gYWNj ZXB0IGENCiAgIFJlY29uZmlndXJlIG1lc3NhZ2UsIGlmIHRoZSBjbGllbnQgaW5kaWNhdGVzIHdp dGggYSBSZWNvbmZpZ3VyZQ0KICAgQWNjZXB0IG9wdGlvbiBpbiB0aGUgU29saWNpdCBtZXNzYWdl IHRoYXQgaXQgd2lsbCBub3QgYWNjZXB0IGENCiAgIFJlY29uZmlndXJlIG1lc3NhZ2UsIHRoZSBz ZXJ2ZXJzIGRpc2NhcmQgdGhlIFNvbGljaXQgbWVzc2FnZS4NCg0KDQoNCkl0IHNob3VsZCBzYXk6 DQoNCg0KDQpGb3IgZXhhbXBsZSwgaWYgdGhlIGFkbWluaXN0cmF0aXZlIHBvbGljeSBmb3IgdGhl IHNlcnZlciBpcyB0aGF0IGl0IG1heSBvbmx5IHJlc3BvbmQgdG8gYSBjbGllbnQgdGhhdCBpcyB3 aWxsaW5nIHRvIGFjY2VwdCBhIFJlY29uZmlndXJlIG1lc3NhZ2UsIGlmIHRoZSBjbGllbnQgZG9l cyBub3QgaW5jbHVkZSBhIFJlY29uZmlndXJlIEFjY2VwdCBvcHRpb24gaW4gdGhlIFNvbGljaXQg bWVzc2FnZSwgdGhlIHNlcnZlcnMgZGlzY2FyZCB0aGUgU29saWNpdCBtZXNzYWdlLg0KDQoNCg0K DQoNCkJlc3QgUmVnYXJkcywNCg0KTGVhZg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQq3orz+yMs6IEJlcm5pZSBWb2x6ICh2b2x6KSBbdm9sekBjaXNjby5jb21d DQq3osvNyrG85DogMjAxMcTqN9TCMzHI1SA5OjU1DQq1vTogTGVhZiB5ZWg7IGRoY3dnQGlldGYu b3JnDQpDYzogUmFscGggRHJvbXMgKHJkcm9tcykNCtb3zOI6IFJFOiBbZGhjd2ddIEl0ZW0gZm9y IHRoZSBFcnJhdGEgLSBTZWN0aW9uIDE3LjIuMSAtIFJGQzMzMTU/DQoNClllcywgdGhpcyB3b3Vs ZCBiZSBhIHVzZWZ1bCBjb3JyZWN0aW9uLiBJIHRoaW5rIGF0IG9uZSBwb2ludCB0aGUgb3B0aW9u IGhhZCBhIHZhbHVlIGFuZCB0aGF0IG1pZ2h0IGJlIHdoeSB0aGlzIHRleHQgaXMgYXMgaXQgaXMg KHdlIG1pc3NlZCBmaXhpbmcgaXQpLg0KDQoNCi0gICAgICAgICAgQmVybmllDQoNCkZyb206IGRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTGVhZiB5ZWgNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDQ6MTMgUE0N ClRvOiBkaGN3Z0BpZXRmLm9yZw0KQ2M6IFJhbHBoIERyb21zIChyZHJvbXMpDQpTdWJqZWN0OiBb ZGhjd2ddIEl0ZW0gZm9yIHRoZSBFcnJhdGEgLSBTZWN0aW9uIDE3LjIuMSAtIFJGQzMzMTU/DQoN Cg0KSSBtaWdodCBnZXQgYSBpdGVtIGZvciB0aGUgRXJyYXRhIGFmdGVyIHJlYWRpbmcgUkZDMzMx NSB0aGlzIG1vcm5pbmcuDQoNCg0KDQpUaGUgd29yZHMgaW4gdGhlIGZvbGxvd2luZyAyIHBhcmFn cmFwaHMgaGF2ZSBhIGNvbmZsaWN0Lg0KDQoNCg0KU2VjdGlvbiAxNy4yLjEgLSBSRkMzMzE1IC0g REhDUHY2IC0gU2VydmVyIEJlaGF2aW9yIC0gUmVjZWlwdCBvZiBTb2xpY2l0IE1lc3NhZ2VzDQoN Cg0KDQogICBGb3IgZXhhbXBsZSwgaWYgdGhlIGFkbWluaXN0cmF0aXZlIHBvbGljeSBmb3IgdGhl IHNlcnZlciBpcw0KICAgdGhhdCBpdCBtYXkgb25seSByZXNwb25kIHRvIGEgY2xpZW50IHRoYXQg aXMgd2lsbGluZyB0byBhY2NlcHQgYQ0KICAgUmVjb25maWd1cmUgbWVzc2FnZSwgaWYgdGhlIGNs aWVudCBpbmRpY2F0ZXMgd2l0aCBhIFJlY29uZmlndXJlDQogICBBY2NlcHQgb3B0aW9uIGluIHRo ZSBTb2xpY2l0IG1lc3NhZ2UgdGhhdCBpdCB3aWxsIG5vdCBhY2NlcHQgYQ0KICAgUmVjb25maWd1 cmUgbWVzc2FnZSwgdGhlIHNlcnZlcnMgZGlzY2FyZCB0aGUgU29saWNpdCBtZXNzYWdlLg0KDQpT ZWN0aW9uIDIyLjIwIC0gUkZDMzMxNSAtIERIQ1B2NiAtIFJlY29uZmlndXJlIEFjY2VwdCBPcHRp b24NCg0KDQoNCiAgIEEgY2xpZW50IHVzZXMgdGhlIFJlY29uZmlndXJlIEFjY2VwdCBvcHRpb24g dG8gYW5ub3VuY2UgdG8gdGhlIHNlcnZlcg0KICAgd2hldGhlciB0aGUgY2xpZW50IGlzIHdpbGxp bmcgdG8gYWNjZXB0IFJlY29uZmlndXJlIG1lc3NhZ2VzLCBhbmQgYQ0KICAgc2VydmVyIHVzZXMg dGhpcyBvcHRpb24gdG8gdGVsbCB0aGUgY2xpZW50IHdoZXRoZXIgb3Igbm90IHRvIGFjY2VwdA0K ICAgUmVjb25maWd1cmUgbWVzc2FnZXMuIFRoZSBkZWZhdWx0IGJlaGF2aW9yLCBpbiB0aGUgYWJz ZW5jZSBvZiB0aGlzDQogICBvcHRpb24sIG1lYW5zIHVud2lsbGluZ25lc3MgdG8gYWNjZXB0IFJl Y29uZmlndXJlIG1lc3NhZ2VzLCBvcg0KICAgaW5zdHJ1Y3Rpb24gbm90IHRvIGFjY2VwdCBSZWNv bmZpZ3VyZSBtZXNzYWdlcywgZm9yIHRoZSBjbGllbnQgYW5kDQogICBzZXJ2ZXIgbWVzc2FnZXMs IHJlc3BlY3RpdmVseS4gVGhlIGZvbGxvd2luZyBmaWd1cmUgZ2l2ZXMgdGhlIGZvcm1hdA0KICAg b2YgdGhlIFJlY29uZmlndXJlIEFjY2VwdCBvcHRpb246DQoNCiAgICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDENCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgIHwgICAgIE9QVElPTl9SRUNPTkZfQUNDRVBUICAgICAgfCAg ICAgICAgICAgICAgIDAgICAgICAgICAgICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgIG9wdGlv bi1jb2RlICAgT1BUSU9OX1JFQ09ORl9BQ0NFUFQgKDIwKS4NCiAgICBvcHRpb24tbGVuICAgIDAu DQoNCg0KDQpJIG1lYW4gdGhlIGNsaWVudCBjYW4gbm90IGluY2x1ZGUgYSBSZWNvbmZpZ3VyZSBB Y2NlcHQgT3B0aW9uIGZvciB0aGUgdW53aWxsaW5nbmVzcyB0byBhY2NlcHQgYSBSZWNvbmZpZ3Vy ZSBtZXNzYWdlIHBlciB0aGUgZGVzY3JpcHRpb24gb2YgUmVjb25maWd1cmUgQWNjZXB0IE9wdGlv biBpbiBTZWN0aW9uIDIyLjIwLg0KDQoNCg0KU28gdGhlIHdvcmRzIGZvciB0aGUgcmV2aXNvbiBp biBzZWN0aW9uIDE3LjIuMSBtaWdodCBiZSAnRm9yIGV4YW1wbGUsIGlmIHRoZSBhZG1pbmlzdHJh dGl2ZSBwb2xpY3kgZm9yIHRoZSBzZXJ2ZXIgaXMgdGhhdCBpdCBtYXkgb25seSByZXNwb25kIHRv IGEgY2xpZW50IHRoYXQgaXMgd2lsbGluZyB0byBhY2NlcHQgYSBSZWNvbmZpZ3VyZSBtZXNzYWdl LCBpZiB0aGUgY2xpZW50IGRvZXMgbm90IGluY2x1ZGUgYSBSZWNvbmZpZ3VyZSBBY2NlcHQgb3B0 aW9uIGluIHRoZSBTb2xpY2l0IG1lc3NhZ2UsIHRoZSBzZXJ2ZXJzIGRpc2NhcmQgdGhlIFNvbGlj aXQgbWVzc2FnZS4nDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpMZWFmDQoNCg0K --Boundary_(ID_5jMRwKRcLk8CzbrEqGmlGQ) Content-id: <0A2EE750B595AF40A80CE28766DE56AE@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi, Alice

 

The author of RFC3315 (Mr. Bernie Volz) and I believe that we need a fix= in the section 17.2.1 of RFC3315.

 

Section 17.2.1 says:

 

   For example, if the administrative policy for the server is=
   that it may only respond to a client that is willing to accept= a
   Reconfigure message, if the client indicates with= a Reconfigure
   Acc= ept option in the Solicit message that it will not accept a=
   Rec= onfigure message, the servers discard the= Solicit message.

 

It should say:

 

For example, if the administrative policy for the server is that it= may only respond to a client that is willing to accept a Reconfigure = message, if the client does not include a Rec= onfigure Accept option in the Solicit message, the servers discard the Solicit message.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Bernie Volz (volz) [vo= lz@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C231=C8=D5 9:55
=B5=BD: Leaf yeh; dhcwg@ietf.org
Cc: Ralph Droms (rdroms)
=D6=F7=CC=E2: RE: [dhcwg] Item for the Errata - Section 17.2.1 - RFC= 3315?

Yes, this would be a useful correction. I = think at one point the option had a value and that might be why this text i= s as it is (we missed fixing it).

 

-    &nbs= p;     Bernie

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@i= etf.org] On Behalf Of Leaf yeh
Sent: Thursday, July 28, 2011 4:13 PM
To: dhcwg@ietf.org
Cc: Ralph Droms (rdroms)
Subject: [dhcwg] Item for the Errata - Section 17.2.1 - RFC3315?

 

I might get a item for the Errata after reading RFC3315 this= morning.

 

The words in the following 2 paragraphs have a conflict.

 

Section 17.2.1 - RFC3315 - DHCPv6 - Server Behavior - Receipt of Solicit Messages

 

   For example, if the administrative policy for the se= rver is
   that it may only respond to a client that is willing to accept= a
   Reconfigure message, if the client indicat= es with a Reconfigure
   Acc= ept option in the Solicit message that it will not accept a=
   Rec= onfigure message, the servers discard the= Solicit message.

Section 22.20 - RFC3315 - DHCPv6 - Reconfigure Accept Option

 

   A client uses the Reconfigure Accept option to annou= nce to the server
   whether the client is willing to accept Reconfigure messages, = and a
   server uses this option to tell the client whether or not to a= ccept
   Reconfigure messages. The default beh= avior, in the absence of this
   opt= ion, means unwillingness to accept Reconfigure messages, or
   instruction not to accept Reconfigure messages, for the client= and
   server messages, respectively. The following figure gives= the format
   of the Reconfigure Accept option:

     0        &= nbsp;          1  &n= bsp;            = ;    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
    +-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
    |     OPTION_RECONF_ACCEPT &nbs= p;    |         = ;      0       =         |
    +-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+

    option-code   OPTION_RECONF_ACCEPT (20).
    option-len    0.

 

I mean the client can not include a Reconfigure Accept Option for= the unwillingness to accept a Reconfigure message per the description= of Reconfigure Accept Option in Section 22.20.

 

So the words for the revison in section 17.2.1 mig= ht be 'For example, if the administrative policy for the server is tha= t it may only respond to a client that is willing to accept a Reconfigure message, if the client does not inc= lude a Reconfigure Accept option in the Solicit message, <= /strong>the servers discard the Solicit message.'

 

 

Best Regards,

Leaf


 

--Boundary_(ID_5jMRwKRcLk8CzbrEqGmlGQ)-- From wwwrun@rfc-editor.org Mon Aug 8 10:54:12 2011 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 CA04821F8B3C for ; Mon, 8 Aug 2011 10:54:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E7 hex): Subject: Re: \347\255\224\345\244\215: [dhcwg] [...] X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SUBJECT_NEEDS_ENCODING=0.001, SUBJ_ILLEGAL_CHARS=1.586, 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 NWKWw+v4rVWB for ; Mon, 8 Aug 2011 10:54:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4177121F8B23 for ; Mon, 8 Aug 2011 10:54:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D207498C518; Mon, 8 Aug 2011 10:54:38 -0700 (PDT) To: Leaf yeh Subject: Re: 答复: [dhcwg] Item for the Errata - Section 17.2.1 - RFC3315? From: rfc-editor@rfc-editor.org Message-Id: <20110808175438.D207498C518@rfc-editor.org> Date: Mon, 8 Aug 2011 10:54:38 -0700 (PDT) Cc: dhcwg@ietf.org, "Bernie Volz \(volz\)" , Ralph Droms , RFC Editor 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 Aug 2011 17:54:12 -0000 Greetings, Please submit errata using 'Report New Errata' here: http://www.rfc-editor.org/errata.php Instructions are here: http://www.rfc-editor.org/how_to_report.html Please let us know if you have questions. Thank you. RFC Editor/ah On Aug 8, 2011, at 12:05 PM, Leaf yeh wrote: > Hi, Alice > > The author of RFC3315 (Mr. Bernie Volz) and I believe that we need a fix in the section 17.2.1 of RFC3315. > > Section 17.2.1 says: > > For example, if the administrative policy for the server is > that it may only respond to a client that is willing to accept a > Reconfigure message, if the client indicates with a Reconfigure > Accept option in the Solicit message that it will not accept a > Reconfigure message, the servers discard the Solicit message. > > It should say: > > For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option in the Solicit message, the servers discard the Solicit message. > > > Best Regards, > Leaf > > > 发件人: Bernie Volz (volz) [volz@cisco.com] > 发送时间: 2011年7月31日 9:55 > 到: Leaf yeh; dhcwg@ietf.org > Cc: Ralph Droms (rdroms) > 主题: RE: [dhcwg] Item for the Errata - Section 17.2.1 - RFC3315? > > Yes, this would be a useful correction. I think at one point the option had a value and that might be why this text is as it is (we missed fixing it). > > - Bernie > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf yeh > Sent: Thursday, July 28, 2011 4:13 PM > To: dhcwg@ietf.org > Cc: Ralph Droms (rdroms) > Subject: [dhcwg] Item for the Errata - Section 17.2.1 - RFC3315? > > I might get a item for the Errata after reading RFC3315 this morning. > > The words in the following 2 paragraphs have a conflict. > > Section 17.2.1 - RFC3315 - DHCPv6 - Server Behavior - Receipt of Solicit Messages > > For example, if the administrative policy for the server is > that it may only respond to a client that is willing to accept a > Reconfigure message, if the client indicates with a Reconfigure > Accept option in the Solicit message that it will not accept a > Reconfigure message, the servers discard the Solicit message. > Section 22.20 - RFC3315 - DHCPv6 - Reconfigure Accept Option > > A client uses the Reconfigure Accept option to announce to the server > whether the client is willing to accept Reconfigure messages, and a > server uses this option to tell the client whether or not to accept > Reconfigure messages. The default behavior, in the absence of this > option, means unwillingness to accept Reconfigure messages, or > instruction not to accept Reconfigure messages, for the client and > server messages, respectively. The following figure gives the format > of the Reconfigure Accept option: > > 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_RECONF_ACCEPT | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > option-code OPTION_RECONF_ACCEPT (20). > option-len 0. > > I mean the client can not include a Reconfigure Accept Option for the unwillingness to accept a Reconfigure message per the description of Reconfigure Accept Option in Section 22.20. > > So the words for the revison in section 17.2.1 might be 'For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option in the Solicit message, the servers discard the Solicit message.' > > > Best Regards, > Leaf > From jiangsheng@huawei.com Mon Aug 8 18:16:04 2011 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 CD22B21F8BEE for ; Mon, 8 Aug 2011 18:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V7uwswp8+vlh for ; Mon, 8 Aug 2011 18:16:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E223121F8BEC for ; Mon, 8 Aug 2011 18:16:03 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPM00L3VZJGAC@szxga03-in.huawei.com> for dhcwg@ietf.org; Tue, 09 Aug 2011 09:16:28 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPM0086WZJFQX@szxga03-in.huawei.com> for dhcwg@ietf.org; Tue, 09 Aug 2011 09:16:28 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB63583; Tue, 09 Aug 2011 09:16:27 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 09 Aug 2011 09:16:25 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Tue, 09 Aug 2011 09:16:28 +0800 Date: Tue, 09 Aug 2011 01:16:25 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.152] To: Ted Lemon Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201229B81@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dje/MY+I7pbDoOQbtMCsDg)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Is address rejection function needed in address registration? Thread-index: AcxRi960lrgFMw+xRgiOtiEi1JKp8gAlRGKAAAjjbtAA1IqbwAAAR0yAACZsP4A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201226008@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B92012285A4@SZXEML506-MBS.china.huawei.com> Cc: dhc WG , ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 01:16:04 -0000 --Boundary_(ID_dje/MY+I7pbDoOQbtMCsDg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Removing the address rejection function it is. We are fine to dedicate the registration function to registration only. The authors will make an update version applying this discussion result. Then, maybe, chairs can call wg adoption in the mail list? Sheng From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Monday, August 08, 2011 10:53 PM To: Jiangsheng Cc: Brzozowski, John; dhc WG; ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? On Aug 8, 2011, at 2:56 AM, Jiangsheng wrote: Now, the only scenario is the requested addresses collision. Is it possible, particularly in the point-to-multipoint network topology? If the scenario is real, we probably need the address rejection function; otherwise, the authors would like to remove it from the address registration procedure. DAD proxy solves this problem, or at least proposes to. So I think if you don't care to solve this problem, you shouldn't feel obligated to do so. A lot of resistance to the draft is a mistaken impression that address rejection is being used as an address allocation control mechanism, so you are going to have a much easier time of it if you take out that part. Also, FWIW, I think DAD proxy is a better solution to the problem anyway. --Boundary_(ID_dje/MY+I7pbDoOQbtMCsDg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Removing the address rejection function it is. We are fine to dedicate the registration function to registration only.

 

The authors will make an update version applying this discussion result. Then, maybe, chairs can call wg adoption in the mail list?

 

Sheng

 

From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Monday, August 08, 2011 10:53 PM
To: Jiangsheng
Cc: Brzozowski, John; dhc WG; ChenGang
Subject: Re: [dhcwg] Is address rejection function needed in address registration?

 

On Aug 8, 2011, at 2:56 AM, Jiangsheng wrote:

Now, the only scenario is the requested addresses collision. Is it possible, particularly in the point-to-multipoint network topology? If the scenario is real, we probably need the address rejection function; otherwise, the authors would like to remove it from the address registration procedure.

 

DAD proxy solves this problem, or at least proposes to.   So I think if you don't care to solve this problem, you shouldn't feel obligated to do so.   A lot of resistance to the draft is a mistaken impression that address rejection is being used as an address allocation control mechanism, so you are going to have a much easier time of it if you take out that part.

 

Also, FWIW, I think DAD proxy is a better solution to the problem anyway.

 

--Boundary_(ID_dje/MY+I7pbDoOQbtMCsDg)-- From Ted.Lemon@nominum.com Mon Aug 8 21:05:14 2011 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 04E8211E808A for ; Mon, 8 Aug 2011 21:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 mMK9UY8VxOAu for ; Mon, 8 Aug 2011 21:05:13 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8011E8086 for ; Mon, 8 Aug 2011 21:05:13 -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 DSNKTkCyDs4o25g9Q55OunZfWalMHMkG216k@postini.com; Mon, 08 Aug 2011 21:05:41 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 1B68B1B8104 for ; Mon, 8 Aug 2011 21:05:34 -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 B0887190052 for ; Mon, 8 Aug 2011 21:05:32 -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.01.0289.001; Mon, 8 Aug 2011 21:05:32 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC on draft-ietf-dhc-pd-exclude Thread-Index: AQHMVkmUHS2r+aRCtE2v2STqZ9Me6Q== Date: Tue, 9 Aug 2011 04:05:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: text/plain; charset="us-ascii" Content-ID: <7F5E40834EF9D744AFA210E52DDF3A50@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC on draft-ietf-dhc-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: Tue, 09 Aug 2011 04:05:14 -0000 The authors have requested a WGLC on this draft. There was support in the= meeting. Please review the draft one last time if you can. If you supp= ort the draft's publication, please say so on the mailing list. If you ob= ject to the draft's publication, please say so on the mailing list. If no= body says anything, the draft will not pass last call. We will make the call on 8/23/2011. Thanks! From Ted.Lemon@nominum.com Mon Aug 8 21:05:45 2011 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 AFE3511E80A8 for ; Mon, 8 Aug 2011 21:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jnY9uJ6TkF5R for ; Mon, 8 Aug 2011 21:05:45 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 027EC11E8086 for ; Mon, 8 Aug 2011 21:05:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTkCyNFgY8emNCsv60SFFieSSUp+0OQgN@postini.com; Mon, 08 Aug 2011 21:06:12 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 528A31B810B for ; Mon, 8 Aug 2011 21:06:12 -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 499FE190052; Mon, 8 Aug 2011 21:06:12 -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.01.0289.001; Mon, 8 Aug 2011 21:06:12 -0700 From: Ted Lemon To: Jiangsheng Thread-Topic: [dhcwg] Is address rejection function needed in address registration? Thread-Index: AQHMUmQKGGqDDUfKmU+n4fTcjXc0EZUM36iAgAYhagCAAIUmgIAArkKAgAAvb4A= Date: Tue, 9 Aug 2011 04:06:11 +0000 Message-ID: <10711430-8DF8-4F65-8980-C0991AE15408@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B9201225291@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201226008@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B92012285A4@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201229B81@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201229B81@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_107114308DF84F658980C0991AE15408nominumcom_" MIME-Version: 1.0 Cc: dhc WG , ChenGang Subject: Re: [dhcwg] Is address rejection function needed in address registration? 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 Aug 2011 04:05:45 -0000 --_000_107114308DF84F658980C0991AE15408nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 8, 2011, at 9:16 PM, Jiangsheng wrote: The authors will make an update version applying this discussion result. Th= en, maybe, chairs can call wg adoption in the mail list? Sounds great. Thanks! --_000_107114308DF84F658980C0991AE15408nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0421A74B25F1CB4291821443DF87A6C1@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 8, 2011, at 9:16 PM, Jiangsheng wrote:
The authors will make an update version applying this dis= cussion result. Then, maybe, chairs can call wg adoption in the mail list?<= /span>

Sounds great.   Thanks!


--_000_107114308DF84F658980C0991AE15408nominumcom_-- From ichiroumakino@gmail.com Tue Aug 9 00:42:16 2011 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 B099921F8A80 for ; Tue, 9 Aug 2011 00:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 i4yvTUHZTvv1 for ; Tue, 9 Aug 2011 00:42:16 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C506021F8A7E for ; Tue, 9 Aug 2011 00:42:15 -0700 (PDT) Received: by wwf5 with SMTP id 5so1597171wwf.13 for ; Tue, 09 Aug 2011 00:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=n9oal8Ris2NFHsUVvq0dsMaqOU6cDlqyEG4dSNyF4AQ=; b=arB2fSwXLj8Gb03UMGm82at2Pyywr0Dw5cuOhtmu/F9UNydPHNg9GFinrLzfTVj266 7qxvhEuymM9dJzCYpYkkWcgLLy9Dn1gy3BiRqwbPIn67IkLc5for9Y1d+lWjQwQOMNtx pnMD8q7qGAU2w/FL0YHwLYRwK/6PaU66Sagsw= Received: by 10.227.197.142 with SMTP id ek14mr2344740wbb.13.1312875763167; Tue, 09 Aug 2011 00:42:43 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-111.cisco.com (dhcp-osl-vl300-64-103-53-111.cisco.com [64.103.53.111]) by mx.google.com with ESMTPS id fm9sm2403574wbb.10.2011.08.09.00.42.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 00:42:41 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 9 Aug 2011 09:42:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1902BA72-A7AB-4635-BCD6-02D781618A29@employees.org> References: To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: dhc WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-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: Tue, 09 Aug 2011 07:42:16 -0000 Ted, > The authors have requested a WGLC on this draft. There was support = in the meeting. Please review the draft one last time if you can. If = you support the draft's publication, please say so on the mailing list. = If you object to the draft's publication, please say so on the mailing = list. If nobody says anything, the draft will not pass last call. >=20 > We will make the call on 8/23/2011. we already did a last call on this document in March. I understand the = two revisions since then has been to update the draft according to WGLC = feedback. is a new WGLC necessary? if it is, I'm still in support (and I'm still biased being one of the = authors). cheers, Ole= From tomasz.mrugalski@gmail.com Tue Aug 9 02:57:15 2011 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 8BD2121F86EE for ; Tue, 9 Aug 2011 02:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rziJTfumA5-5 for ; Tue, 9 Aug 2011 02:57:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBB0C21F86EC for ; Tue, 9 Aug 2011 02:57:14 -0700 (PDT) Received: by wwf5 with SMTP id 5so1665696wwf.13 for ; Tue, 09 Aug 2011 02:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=NGRlsF0MaEGCj5X9eCls/eog3ewascBbLszgW5u7K4g=; b=XQLWgEdHshj8u24iq2cQKaFpJr9gveu/it40NHkTw6I6RymxRqzyvwycVBYjqLVIF0 lKXAUuKSGebilHnRHzy1Z1kdXcJtBdHb7Vkw1BYPGHsZEeXjSqnuKq8Q/2g2ROW25YRU 10LyOgxUy8C1Ss/rworA4XqP5qQUrW/3xtpEA= Received: by 10.227.133.144 with SMTP id f16mr5435025wbt.97.1312883860978; Tue, 09 Aug 2011 02:57:40 -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 ESMTPS id o19sm5175681wbh.43.2011.08.09.02.57.38 (version=SSLv3 cipher=OTHER); Tue, 09 Aug 2011 02:57:39 -0700 (PDT) Message-ID: <4E410491.70900@gmail.com> Date: Tue, 09 Aug 2011 11:57:37 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dhcwg@ietf.org References: In-Reply-To: X-TagToolbar-Keys: D20110809115737825 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-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: Tue, 09 Aug 2011 09:57:15 -0000 On 09.08.2011 06:05, Ted Lemon wrote: > The authors have requested a WGLC on this draft. There was support > in the meeting. Please review the draft one last time if you can. > If you support the draft's publication, please say so on the mailing > list. If you object to the draft's publication, please say so on > the mailing list. If nobody says anything, the draft will not pass > last call. I read the latest (draft-ietf-dhc-pd-exclude-03) version of this draft. I support it. I have no further comments. It is ready for publication in my opinion. Tomek From tjc@ecs.soton.ac.uk Tue Aug 9 05:44:58 2011 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 DE61121F8ABB for ; Tue, 9 Aug 2011 05:44:58 -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 TI+TNUjYuGsl for ; Tue, 9 Aug 2011 05:44:58 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E35CA21F8AA9 for ; Tue, 9 Aug 2011 05:44:57 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p79CjJ2N003803 for ; Tue, 9 Aug 2011 13:45:19 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p79CjJ2N003803 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1312893919; bh=xbnKiuCE6nD740faRd0VQUQQH94=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=HP5Y4Un57wry69EgpG7PM6svJAh8Ks7928kVMNVhCYWpKy4fGXqN/czm9XFyCd6IY X911m90Irc2VagI4eSinKTz0q9LkU4TY9qepHt6UmzWAqVrqwxSEachYFk2C7LHhjg Aa5JVqDzi2AY75bzWfq6SE8tuV3rQHlNrelqnsvE= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n78DjJ0366150340YM ret-id none; Tue, 09 Aug 2011 13:45:19 +0100 Received: from [IPv6:2001:630:d0:f105:69cf:dfd3:4fbe:f33d] ([IPv6:2001:630:d0:f105:69cf:dfd3:4fbe:f33d]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p79CjDf4018861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Aug 2011 13:45:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <4E410491.70900@gmail.com> Date: Tue, 9 Aug 2011 13:44:55 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <4E410491.70900@gmail.com> <216ED372-50EC-42D5-A597-54C5C7358F29@ecs.soton.ac.uk> To: dhcwg@ietf.org X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n78DjJ036615034000; tid=n78DjJ0366150340YM; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p79CjJ2N003803 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-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: Tue, 09 Aug 2011 12:44:59 -0000 On 9 Aug 2011, at 10:57, Tomasz Mrugalski wrote: > On 09.08.2011 06:05, Ted Lemon wrote: >> The authors have requested a WGLC on this draft. There was support >> in the meeting. Please review the draft one last time if you can. >> If you support the draft's publication, please say so on the mailing >> list. If you object to the draft's publication, please say so on >> the mailing list. If nobody says anything, the draft will not pass >> last call. > I read the latest (draft-ietf-dhc-pd-exclude-03) version of this draft. > I support it. I have no further comments. It is ready for publication in > my opinion. I support this draft. Tim From jyrki.soini@teliasonera.com Tue Aug 9 06:25:47 2011 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 DB80021F8BD5 for ; Tue, 9 Aug 2011 06:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y1Ay9YmuEKF5 for ; Tue, 9 Aug 2011 06:25:47 -0700 (PDT) Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4479621F8BC5 for ; Tue, 9 Aug 2011 06:25:47 -0700 (PDT) X-Originating-Ip: [131.177.70.25] Received: from smtp.extra.sonera.fi (smtp.extra.sonera.fi [131.177.70.25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.tele.fi (Postfix) with ESMTP id 5D72B2521; Tue, 9 Aug 2011 16:26:14 +0300 (EEST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.120.25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.extra.sonera.fi (Postfix) with ESMTP id 655361EE9E6; Tue, 9 Aug 2011 16:26:13 +0300 (EEST) Received: from [131.177.117.245] (ws1245.secureuser.sonera.fi [131.177.117.245]) by smtp.dave.sonera.fi (Postfix) with ESMTP id 7122458038; Tue, 9 Aug 2011 16:26:12 +0300 (EEST) Message-ID: <4E413574.6040807@teliasonera.com> Date: Tue, 09 Aug 2011 16:26:12 +0300 From: Jyrki Soini User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Ted Lemon References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhc WG Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-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: Tue, 09 Aug 2011 13:25:48 -0000 On 21:59, Ted Lemon wrote: > The authors have requested a WGLC on this draft. There was support in the meeting. Please review the draft one last time if you can. If you support the draft's publication, please say so on the mailing list. If you object to the draft's publication, please say so on the mailing list. If nobody says anything, the draft will not pass last call. > > We will make the call on 8/23/2011. > > Thanks! > > I have read the latest version and support the draft. -- Jyrki Soini From jiangsheng@huawei.com Tue Aug 9 19:06:57 2011 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 BE8E321F856C for ; Tue, 9 Aug 2011 19:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 nsN6X-6EjrOj for ; Tue, 9 Aug 2011 19:06:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E34A421F8434 for ; Tue, 9 Aug 2011 19:06:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00JGCWJ0TK@szxga03-in.huawei.com> for dhcwg@ietf.org; Wed, 10 Aug 2011 10:06:36 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00DUIWJ0CP@szxga03-in.huawei.com> for dhcwg@ietf.org; Wed, 10 Aug 2011 10:06:36 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC08638; Wed, 10 Aug 2011 10:06:36 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 10:06:30 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 10:06:31 +0800 Date: Wed, 10 Aug 2011 02:06:29 +0000 From: Jiangsheng X-Originating-IP: [10.110.98.152] To: dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122AC90@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Review of draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 Thread-index: AcxXAh0PeFUimIX3TQWWRYTKDNXv6Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [dhcwg] Review of draft-ietf-dhc-dhcpv6-reconfigure-rebind-07 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 Aug 2011 02:06:57 -0000 I have reviewed draft-ietf-dhc-dhcpv6-reconfigure-rebind-07. In general, this draft has proposed an useful scenario, but the description of motivation and suitable scenario is not very clear. It starts from the statement "the server to indicate that the client is to send a Rebind message", but only have one sentence to explain the motivation scenario. Even in this single sentence, it used "Under some circumstances, it may be desirable". This does not look very convince, or itself shows the requirement is weak and unsure. Personally, I think the requirement is real, but need better description. (If additional efforts are needed here, I can help.) The other parts of this draft, including Reconfigure Message option, server behave and client behave, updates correspondent part in RFC3315. They are straight forward with little controversy. A small error there: "4.1. client behaviour" is not belong to the title of "4. server behaviour". It should be either an independent section or change section 4 title to be "server and client behaviour". Sheng From leaf.y.yeh@huawei.com Wed Aug 10 20:36:16 2011 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 9F6DE21F8B43 for ; Wed, 10 Aug 2011 20:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.314 X-Spam-Level: X-Spam-Status: No, score=-4.314 tagged_above=-999 required=5 tests=[AWL=2.285, 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 bDaQ3Sb48FE8 for ; Wed, 10 Aug 2011 20:36:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB221F8B3A for ; Wed, 10 Aug 2011 20:36:15 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPQ0017AVBWPZ@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 11 Aug 2011 11:35:56 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPQ00MWSVBS99@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 11 Aug 2011 11:35:56 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC08570; Thu, 11 Aug 2011 11:35:56 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 11:35:52 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.116]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 11:35:56 +0800 Date: Thu, 11 Aug 2011 03:35:55 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.86] To: "Brzozowski, John" , dhc WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: IETF81 dhcwg - volunteers for minutes and jabber Thread-index: AQHMSaD+e0IJbs8cdUOblb1DRpGW1ZT/9U4AgBck5CA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [dhcwg] IETF81 dhcwg - volunteers for minutes and jabber 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 Aug 2011 03:36:16 -0000 Hi, John Is our minutes for DHC session of IETF81 available? Best Regards, Leaf PS. http://www.ietf.org/proceedings/81/minutes -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Brzozowski, John Sent: Thursday, July 28, 2011 2:02 AM To: dhc WG Subject: Re: [dhcwg] IETF81 dhcwg - volunteers for minutes and jabber Any volunteers please contact the chairs. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 7/23/11 9:28 PM, "John Jason Brzozowski" wrote: >The dhcwg chair would like volunteers to take meeting minutes and for >jabber scribing during our upcoming working group meeting in Quebec City. > >Meeting details can be found here: > >http://www.ietf.org/proceedings/81/agenda/dhc.html > >Thanks, > >Ted and John > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Wed Aug 10 20:54:14 2011 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 84C7621F85EC for ; Wed, 10 Aug 2011 20:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 0gWJtXGJ2Rv8 for ; Wed, 10 Aug 2011 20:54:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1D821F85C7 for ; Wed, 10 Aug 2011 20:54:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPQ00HHQW77X6@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 11 Aug 2011 11:54:43 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPQ0088YW617H@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 11 Aug 2011 11:54:43 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC10546; Thu, 11 Aug 2011 11:54:43 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 11:54:38 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 11:54:42 +0800 Date: Thu, 11 Aug 2011 03:54:41 +0000 From: Jiangsheng X-Originating-IP: [10.110.98.152] To: dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122B3C3@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: New Version Notification for draft-jiang-dhc-addr-registration-03.txt Thread-index: AQHMV9dz2ICsYYIrzEOfHzj/CuHRo5UXBDCA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [dhcwg] FW: New Version Notification for draft-jiang-dhc-addr-registration-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: Thu, 11 Aug 2011 03:54:14 -0000 The authors has updated this draft according to recent discussion on the mail list - removing the address rejection function. Another modification that is worth mentioning is we use FQDN replace address of address registration server in the solicitation options. We believe the FQDN has many advantage over address. Best regards, Sheng > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, August 11, 2011 11:33 AM > To: Jiangsheng > Cc: phdgang@gmail.com; Jiangsheng > Subject: New Version Notification for draft-jiang-dhc-addr- > registration-03.txt > > A new version of I-D, draft-jiang-dhc-addr-registration-03.txt has been > successfully submitted by Sheng Jiang and posted to the IETF repository. > > Filename: draft-jiang-dhc-addr-registration > Revision: 03 > Title: A Generic IPv6 Addresses Registration Solution Using > DHCPv6 > Creation date: 2011-08-11 > WG ID: Individual Submission > Number of pages: 10 > > Abstract: > In the IPv6 address allocation scenarios, host self-generated > addresses are notionally conflicted with the network managed address > architecture. These addresses need to be registered in the > networking > management plate for the purposes of central address administration. > This document introduces a generic address registration solution > using DHCPv6, and defines one new ND option and one new DHCPv6 > option > in order to propagate the solicitations of registering self- > generated > addresses. The registration procedure reuses the existing IA_NA in > the DHCPv6 protocol. > > > > > The IETF Secretariat From jiangsheng@huawei.com Thu Aug 11 01:18:12 2011 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 BF6ED21F88A1 for ; Thu, 11 Aug 2011 01:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 e1KuHplm1dWA for ; Thu, 11 Aug 2011 01:18:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8210F21F889D for ; Thu, 11 Aug 2011 01:18:11 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR004DO8BYFF@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 11 Aug 2011 16:16:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR00C4R8BY3M@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 11 Aug 2011 16:16:46 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC35463; Thu, 11 Aug 2011 16:16:45 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 16:16:40 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 16:16:45 +0800 Date: Thu, 11 Aug 2011 08:16:44 +0000 From: Jiangsheng X-Originating-IP: [10.110.98.152] To: dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122B5BD@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Review of draft-ietf-dhc-option-guidelines Thread-index: AcxX/wF+rNDlhGCESMaq982wYvF4KQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [dhcwg] Review of draft-ietf-dhc-option-guidelines 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 Aug 2011 08:18:12 -0000 Hi, all, As agreed in the IETF 81 meeting, I have reviewed draft-ietf-dhc-option-guidelines and have below comments. Overall, this guideline is very useful. If it was published, it should be recommended in DHC WG charter page. 1. The very first and maybe the most important comment is: it is better to separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts for DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different protocols. Some of discussions may be common between them, some of discussion may have very different base. Combining this discussion may harmful. Section 9, "option size" is an example. The option size requirements for DHCPv4 and DHCPv6 are different. Separating them would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option. Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines for new DHCPv4 option may be meaningless. 2. In the introduction section, this draft mentioned support for unknown options. It is unclear for me, at least from the draft contents, how this can happen? It may be possible to add new option at the server side, how the client support it? 3. The section 2, "when to use DHCP" does not mentioned "IP address configuration", which is the most important usage of DHCP. Unless this text is dedicate for new DHCP option (the current text does not claim so), IP address configuration should be added. 4. Disagree on the order of "when to use DHCP". The current text suggests using DHCP is first because client want information. But, in my understanding, network administration want to push/enforce some configuration is the most important requirements. 5. The draft states, in section 2, "the client still reserves the right to ignore values received via DHCP". That's right. But this may be at their own risk to be rejected by network administration. This kind of observation should also mentioned. Otherwise, the above next may be misleading: client can ignore DHCP configuration without any effect. 6. At the end of section 4, there are some rules how to organize values in the option. There should be more, such as the order of fixed size values, the order of multiple variable sized values. 7. section 5, using the conclusion as title can be more explicit: "avoid conditional formatting". This also looks like the title of section 6. 8. the title of section 6 has a typo: avoid alciasing/aliasing 9. "in the case where the server is configured with all formats, DHCP option space is wasted on option contents that are redundant". This is not necessary true - usage of sub-option can reduce the dhcp option type to be only 1. Although the usage of sub-option is not recommended in the next section. The readers may have question here. Suggest to add one sentence for sub-option and refer to next section. 10. Title of section 7 is misleading. It looks like it will introduce several new formats in this section. Suggest to change as "consideration on creating new formats". 11. in Section 9, the discussion regarding to DHCPv6 cannot draw the conclusion "prefer option formats...in the SMALLEST form factor". Be clear, I do agree the conclusion, but not the analysis. 12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios. 13. This draft says nothing about option orders, which is also important. The principle should be not give any specific order when design a new DHCP option. The option should be allowed to appear any place in the DHCP message. The only exception is security option(s). They need to perform algorithm over all other options. They may be allowed to located at the end. 14. draft-ietf-dhc-secure-dhcpv6 should be mentioned in the security consideration section. If it deployed, some threats, like man-in-middle can be prevented since it introduced an data integrity protection for DHCPv6 messages. 15. The text regarding to fixed/variable length options in security consideration section looks mis-located for me. They are not security relevant. Best regards, Sheng From jiangsheng@huawei.com Fri Aug 12 02:41:52 2011 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 8E86F21F8745 for ; Fri, 12 Aug 2011 02:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 yHzdoaGFvQo1 for ; Fri, 12 Aug 2011 02:41:52 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D9C9621F8726 for ; Fri, 12 Aug 2011 02:41:51 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPT006486WAV9@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 12 Aug 2011 17:40:58 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPT006RN6UEIZ@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 12 Aug 2011 17:40:58 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADD29939; Fri, 12 Aug 2011 17:40:57 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 17:40:50 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 17:40:56 +0800 Date: Fri, 12 Aug 2011 09:40:55 +0000 From: Sheng Jiang X-Originating-IP: [10.110.98.152] To: dhc WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122BF40@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Review of draft-ietf-mif-dhcpv6-route-option Thread-index: AcxY0+7labjfGCrCSzWpVZGOWYwBWg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option 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 Aug 2011 09:41:52 -0000 Hi, all, As agreed in the IETF 81 meeting, I have reviewed draft-ietf-mif-dhcpv6-route-option and have below comments. Since I am reviewing this draft on behalf of DHC wg. I only focus on whether this design fits DHCPv6 protocol and its regulations. I don't really review technology requirements or mechanism design of this draft. Overall, it is right to use DHCPv6 protocol to carry this kind of configuration information, which need to be propagated from network to end-host. The major issue I have for this draft is: why design an IA container if "client will never use more than one IA_RT" (stated in this draft) and it has only one sub-option - Next Hop option. For me, it seems more explicit and simple to directly define Next Hop Option and allow multiple Next Hop Option if needed. Several minor comments: there is no term explanation for IA_RT. It is helpful to indicate IA_RT option is variable length in Figure 1 and its text. I-D.troan-multihoming-without-nat66 has been replaced by draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. Best regards, Sheng From wwwrun@rfc-editor.org Tue Aug 9 07:48:33 2011 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 B06A621F8C00 for ; Tue, 9 Aug 2011 07:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, 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 PgbzlBoCj+mr for ; Tue, 9 Aug 2011 07:48:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 404E721F8BFE for ; Tue, 9 Aug 2011 07:48:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3DF1398C51C; Tue, 9 Aug 2011 07:49:02 -0700 (PDT) To: Jim.Bound@hp.com, volz@metrocast.net, Ted.Lemon@nominum.com, charles.perkins@nokia.com, michael.carney@sun.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ted.lemon@nominum.com, john_brzozowski@cable.comcast.com From: RFC Errata System Message-Id: <20110809144902.3DF1398C51C@rfc-editor.org> Date: Tue, 9 Aug 2011 07:49:02 -0700 (PDT) X-Mailman-Approved-At: Fri, 12 Aug 2011 08:06:54 -0700 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] [Technical Errata Reported] RFC3315 (2928) 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 Aug 2011 14:48:33 -0000 The following errata report has been submitted for RFC3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3315&eid=2928 -------------------------------------- Type: Technical Reported by: Leaf Yeh Section: 17.2.1 Original Text ------------- For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message. Corrected Text -------------- For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option (see section 22.20) in the Solicit message, the servers discard the Solicit message. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3315 (draft-ietf-dhc-dhcpv6-28) -------------------------------------- Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Publication Date : July 2003 Author(s) : R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From Ted.Lemon@nominum.com Fri Aug 12 09:32:06 2011 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 0A66521F8549 for ; Fri, 12 Aug 2011 09:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VXE76wsusgYz for ; Fri, 12 Aug 2011 09:32:04 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 542C521F84CF for ; Fri, 12 Aug 2011 09:32:04 -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 DSNKTkVVqRtV/bTKG0kVHOXssTFXlcxMQ1rq@postini.com; Fri, 12 Aug 2011 09:32:42 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 829CD1B8163 for ; Fri, 12 Aug 2011 09:32:41 -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 A276D190052; Fri, 12 Aug 2011 09:32:34 -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.01.0289.001; Fri, 12 Aug 2011 09:32:34 -0700 From: Ted Lemon To: Sheng Jiang Thread-Topic: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option Thread-Index: AcxY0+7labjfGCrCSzWpVZGOWYwBWgAdCv2A Date: Fri, 12 Aug 2011 16:32:34 +0000 Message-ID: <4271D8B5-93A8-4D4D-99BA-957FC85C294E@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B920122BF40@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B920122BF40@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_4271D8B593A84D4D99BA957FC85C294Enominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option 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 Aug 2011 16:32:06 -0000 --_000_4271D8B593A84D4D99BA957FC85C294Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 12, 2011, at 5:40 AM, Sheng Jiang wrote: The major issue I have for this draft is: why design an IA container if "cl= ient will never use more than one IA_RT" (stated in this draft) and it has = only one sub-option - Next Hop option. For me, it seems more explicit and s= imple to directly define Next Hop Option and allow multiple Next Hop Option= if needed. If it really is the case that there is only going to be one suboption, I th= ink you are correct. --_000_4271D8B593A84D4D99BA957FC85C294Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 12, 2011, at 5:40 AM, Sheng Jiang wrote:
The major issue I have for this draft is: why design an IA container if "= client will never use more than one IA_RT" (stated in this draft) and = it has only one sub-option - Next Hop option. For me, it seems more explici= t and simple to directly define Next Hop Option and allow multiple Next Hop Option if needed.

If it really is the case that there is only going to be one suboption,= I think you are correct.

--_000_4271D8B593A84D4D99BA957FC85C294Enominumcom_-- From internet-drafts@ietf.org Fri Aug 12 10:25:03 2011 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 3C78211E8088; Fri, 12 Aug 2011 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 vsF9M-GMZmSS; Fri, 12 Aug 2011 10:25:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6079511E8083; Fri, 12 Aug 2011 10:25:02 -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: 3.57 Message-ID: <20110812172502.26183.53045.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2011 10:25:02 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-redundancy-consider-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: Fri, 12 Aug 2011 17:25:03 -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 Gr= oup of the IETF. Title : DHCPv6 Redundancy Deployment Considerations Author(s) : John Jason Brzozowski Jean-Francois Tremblay Jack Chen Tomasz Mrugalski Filename : draft-ietf-dhc-dhcpv6-redundancy-consider-01.txt Pages : 16 Date : 2011-08-12 This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-redundancy-consid= er-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-redundancy-conside= r-01.txt From tomasz.mrugalski@gmail.com Fri Aug 12 10:36:49 2011 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 18E8711E8088 for ; Fri, 12 Aug 2011 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uAaYe91umNDl for ; Fri, 12 Aug 2011 10:36:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F94F11E8080 for ; Fri, 12 Aug 2011 10:36:48 -0700 (PDT) Received: by wyg8 with SMTP id 8so2654678wyg.31 for ; Fri, 12 Aug 2011 10:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=ueflVdMRpBcHnzsG9auKOTNN4rfGo5ciO6MPf/akLCI=; b=XzuKOihTLPI+jD3AfxliaOcgXrCT5t74+h/K2i/6rwCl05TNurXyRaENBp6Fh1xUw4 eHyLPhatokOimmTwSh6Js/WsEBhOFolPTaLcizZF8NKSg7sSOycdCStiKgOdRFTqXVuO kZGcnyMlBcNwXiwLgjleGJm/dvZoa+xcteR94= Received: by 10.216.160.4 with SMTP id t4mr3100086wek.109.1313170645280; Fri, 12 Aug 2011 10:37:25 -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 ESMTPS id o19sm2487455wbh.60.2011.08.12.10.37.22 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 10:37:23 -0700 (PDT) Message-ID: <4E4564D1.4060607@gmail.com> Date: Fri, 12 Aug 2011 19:37:21 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20110812172502.26183.53045.idtracker@ietfa.amsl.com> In-Reply-To: <20110812172502.26183.53045.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20110812193721935 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Redundancy considerations draft - a request for WGLC 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 Aug 2011 17:36:49 -0000 On 12.08.2011 19:25, 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 Redundancy Deployment Considerations > Author(s) : John Jason Brzozowski > Jean-Francois Tremblay > Jack Chen > Tomasz Mrugalski > Filename : draft-ietf-dhc-dhcpv6-redundancy-consider-01.txt > Pages : 16 > Date : 2011-08-12 > > This document documents some deployment considerations for those who > wishing to use DHCPv6 to support their deployment of IPv6. > Specifically, providing semi-redundant DHCPv6 services is discussed > in this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-redundancy-consider-01.txt Dear group, An updated version of DHCPv6 Redundancy considerations draft was updated. Section about DNS Update issues has been corrected, thanks to comments from David Hankins, Ted Lemon and Bernie Volz. Thanks! During recent presentation in Quebec, it was suggested that work on this document is mostly done. Authors believe that this draft is ready. Therefore I'd like to ask chairs to announce WGLC for this document. Thanks, Tomek From tomasz.mrugalski@gmail.com Fri Aug 12 10:48:44 2011 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 7CCA721F85F1 for ; Fri, 12 Aug 2011 10:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 OrZudrhDfRdk for ; Fri, 12 Aug 2011 10:48:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1062421F85C6 for ; Fri, 12 Aug 2011 10:48:39 -0700 (PDT) Received: by wwf5 with SMTP id 5so2193347wwf.13 for ; Fri, 12 Aug 2011 10:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=wWEKPdFSjOzSiCldcDY+huATMpEu5+VgrS2wE3ywAJQ=; b=us3vtTN9qhGqu6KOBkC8QD2KL18cG2S2rkHecEe9uI1IcLhMfOBUOMq7gm/+0WC037 O3pIW8VV1VsJipWv5iFXkah/7M58ut6VB/TgPox9zvSaLSEpt/+WgknmCQT/OAXH0FEt vXW+DirSwYUISP5qBJW3PnVHQ4mLUeyfYt4yc= Received: by 10.227.176.65 with SMTP id bd1mr1063527wbb.78.1313171357156; Fri, 12 Aug 2011 10:49:17 -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 ESMTPS id ez4sm539433wbb.63.2011.08.12.10.49.15 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 10:49:16 -0700 (PDT) Message-ID: <4E45679A.1020301@gmail.com> Date: Fri, 12 Aug 2011 19:49:14 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Failover Requirements - Request for adoption 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 Aug 2011 17:48:44 -0000 Dear chairs, Dear group, DHCPv6 failover requirements draft was presented in last DHC meeting. There was rather significant support from folks in the room, nobody was against. I would like to briefly summarize history behind this draft. Although it is initial individual submission (-00), this draft went through multiple rounds of reviews by many members of this group. We had several weekly meetings. See WG list archives if you are interested in more details. Three authors of original DHCPv4 failover spec joined the DHCPv6 design team. 20 people working for various vendors, operators, implementors and universities participated in meeting that led to this draft. 10 people actually contributed in various ways. I suppose we could count participating people as supporters. Therefore I'd like ask chairs to announce call for adoption of draft-mrugalski-dhc-dhcpv6-failover-requirements-00 as a WG item. If you have any objections, please raise them now. Thanks, Tomek From wwwrun@rfc-editor.org Fri Aug 12 16:57:27 2011 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 7882F21F8AFF; Fri, 12 Aug 2011 16:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 eDZBb3Of4nlU; Fri, 12 Aug 2011 16:57:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69321F8AFE; Fri, 12 Aug 2011 16:57:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E6A3998C24D; Fri, 12 Aug 2011 16:58:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110812235802.E6A3998C24D@rfc-editor.org> Date: Fri, 12 Aug 2011 16:58:02 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6355 on Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) 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 Aug 2011 23:57:27 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6355 Title: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) Author: T. Narten, J. Johnson Status: Standards Track Stream: IETF Date: August 2011 Mailbox: narten@us.ibm.com, jarrod.b.johnson@gmail.com Pages: 5 Characters: 11453 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-duid-uuid-03.txt URL: http://www.rfc-editor.org/rfc/rfc6355.txt This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ghalwasi@cisco.com Sun Aug 14 03:02:15 2011 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 D4FF821F8556 for ; Sun, 14 Aug 2011 03:02:15 -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 Y9YHNj1hzBhx for ; Sun, 14 Aug 2011 03:02:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD6421F8532 for ; Sun, 14 Aug 2011 03:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=6388; q=dns/txt; s=iport; t=1313316176; x=1314525776; h=mime-version:subject:date:message-id:from:to; bh=BSH7m2nJC/6GJEe4oautoneUVLTF2ZsidL8bQuOBTZc=; b=B/Ns/Pf5/hQVwNMNUenL1cV8tfAjGmmDCg68NXg9B80scKqZl5OkMFZa cVB/UaxhQgGMr3cNTqL5og5tAwi5c3CRjR9MG+smLH9QRrSGmPVvVOzQ6 xlxaQ/fkYju5iCpW3ydWoS1WX8g2NGbzFF9NSySgD8FmQNRZqJefKQA4y k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQHAASdR05Io8UR/2dsb2JhbABBgk2WIo8Jd4E5BwEBAQEDEgEJEQNbAQgiBhgHVwEECxAamzaBIwGdMYVoXwSHXZBKi2g X-IronPort-AV: E=Sophos;i="4.67,369,1309737600"; d="scan'208,217";a="110675092" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2011 10:02:54 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7EA2rZB014975 for ; Sun, 14 Aug 2011 10:02:53 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Aug 2011 15:32:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5A69.552925B7" Date: Sun, 14 Aug 2011 15:32:45 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B8103EBDB97@XMB-BGL-41E.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude Thread-Index: AcxaaVB8jYKT3AUxQQ2445Aj9Og56w== From: "Gaurav Halwasia (ghalwasi)" To: X-OriginalArrivalTime: 14 Aug 2011 10:02:53.0607 (UTC) FILETIME=[554CE370:01CC5A69] Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-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 Aug 2011 10:02:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5A69.552925B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I read the latest version of this draft and I do have a comment. =20 1.) Section 4.1 =20 "A requesting router includes an OPTION_ORO option with the OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, Rebind or Confirm message to inform the delegating router about the support for the prefix delegation functionality defined in this specification." =20 Section 12.1 of RFC 3633 says the CONFIRM messages are not used with DHCPv6 PD.=20 But I do see a reference to CONFIRM message in the above section. Are we updating RFC 3633 w.r.t CONFIRM message support for PD or it's just that we included the reference to CONFIRM message in this text by mistake.? =20 Apart from this I strongly support this draft.=20 =20 =20 Thanks, Gaurav ------_=_NextPart_001_01CC5A69.552925B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

I read the latest version of this = draft and I do have a comment.

 

1.) Section = 4.1

 

 “A requesting router = includes an OPTION_ORO option with the

   OPTION_PD_EXCLUDE option = code in a Solicit, Request, Renew, Rebind = or

   Confirm message to = inform the delegating router about the support = for

   the prefix delegation = functionality defined in this = specification.”

 

Section 12.1 of RFC 3633 says the = CONFIRM messages are not used with DHCPv6 PD. =

But I do see a reference to CONFIRM = message in the above section. Are we updating RFC 3633 w.r.t CONFIRM = message support for PD or it’s just that we included the reference = to CONFIRM message in this text by = mistake.?

 

Apart from this I strongly support = this draft.

 

 

Thanks,

Gaurav

------_=_NextPart_001_01CC5A69.552925B7-- From ichiroumakino@gmail.com Sun Aug 14 04:24:59 2011 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 BD2F421F85FF for ; Sun, 14 Aug 2011 04:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 knE-MD12r11Q for ; Sun, 14 Aug 2011 04:24:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1F321F85BB for ; Sun, 14 Aug 2011 04:24:58 -0700 (PDT) Received: by fxe6 with SMTP id 6so3436125fxe.31 for ; Sun, 14 Aug 2011 04:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fQHThOfIR23v1hy5JtZA9GUgsB1dXpLMDRoNrYbylIs=; b=uK65wo2o5tg+SK3QYq+QTC+N+5m+LAswdg9sqJXfIhbcoadIQX1oXZGGwRV7WhZClQ zI+JHrOO05h6gTUgT+7rNznbfDuDvLid6dPJQ4TxBCX8ap3zBkV8jcMdF1QLAMwykt16 JQkYD071prK7iYQGsqEwbR9awAL0aJ1buDfOw= Received: by 10.223.6.155 with SMTP id 27mr3972098faz.1.1313321140973; Sun, 14 Aug 2011 04:25:40 -0700 (PDT) Received: from dhcp-10-55-85-179.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id y21sm1164395faj.47.2011.08.14.04.25.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Aug 2011 04:25:38 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B8103EBDB97@XMB-BGL-41E.cisco.com> Date: Sun, 14 Aug 2011 13:25:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3CF88B99A9ED504197498BC6F6F04B8103EBDB97@XMB-BGL-41E.cisco.com> To: Gaurav Halwasia (ghalwasi) X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-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 Aug 2011 11:24:59 -0000 Gaurav, > I read the latest version of this draft and I do have a comment. > =20 > 1.) Section 4.1 > =20 > =93A requesting router includes an OPTION_ORO option with the > OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, Rebind = or > Confirm message to inform the delegating router about the support = for > the prefix delegation functionality defined in this specification.=94= > =20 > Section 12.1 of RFC 3633 says the CONFIRM messages are not used with = DHCPv6 PD. > But I do see a reference to CONFIRM message in the above section. Are = we updating RFC 3633 w.r.t CONFIRM message support for PD or it=92s just = that we included the reference to CONFIRM message in this text by = mistake.? thanks, that's a mistake. we'll get that fixed in auth48 if not before. cheers, Ole= From leaf.y.yeh@huawei.com Mon Aug 15 09:12:50 2011 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 35D9421F8C2B for ; Mon, 15 Aug 2011 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 bGtuClJXVKkH for ; Mon, 15 Aug 2011 09:12:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE021F8C16 for ; Mon, 15 Aug 2011 09:12:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPZ00CQZ92IDQ@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 16 Aug 2011 00:13:30 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPZ00LXK92HAK@szxga05-in.huawei.com> for dhcwg@ietf.org; Tue, 16 Aug 2011 00:13:30 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADE91001; Tue, 16 Aug 2011 00:13:28 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 16 Aug 2011 00:13:26 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.116]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Tue, 16 Aug 2011 00:13:28 +0800 Date: Mon, 15 Aug 2011 16:13:27 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [172.24.2.41] To: "dhcwg@ietf.org" Message-id: <952C7031-7E6B-4D97-8016-3B9BAB9A9162@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ewrEZ9ypjii/tXp8RMlv0g)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-05.txt Thread-index: AQHMSv2XEGXzHtFi+Uu3WBWbJ98yDpUeKBTRgAAOhec= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110725170304.18652.99891.idtracker@ietfa.amsl.com> Cc: "draft-yeh-dhc-dhcpv6-prefix-pool-opt@tools.ietf.org" Subject: Re: [dhcwg] New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-05.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 Aug 2011 16:12:50 -0000 --Boundary_(ID_ewrEZ9ypjii/tXp8RMlv0g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 RGVhciBHcm91cCwNCg0KDQoNCkR1cmluZyBJRVRGODEgaW4gUXVlYmVjIGNpdHksIHRoZSBhdXRo b3JzIG9mIGRyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdCB1cGRhdGVkIGl0IHRv IGJlIHZlci4tMDUsIGFuZCBwcmVzZW50ZWQgdGhlIHByb2dyZXNzIG9mIGl0IGluIHRoZSBESEMg c2Vzc2lvbiAoUGxzLiByZWZlciB0byAxNC1kcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9v bC1vcHQtMDU8aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvZGhjLTIu cGRmPikuICBZb3UgY2FuIGFsc28gZmluZCB0aGUgbG9nIG9mIGNoYW5nZXMgaW4gc2VjdGlvbiAx MCBvZiB0aGlzIGRyYWZ0LiBBZ2FpbiAyIHdlZWtzIGFmdGVyIElFVEY4MSwgdGhlIGRyYWZ0IGlz IHN0aWxsIGxvb2tpbmcgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMgZmVlZGluZyBmb3IgdGhl IGZ1cnRoZXIgZGlzY3Vzc2lvbi4NCg0KDQoNCkkgd291bGRuJ3Qgd2FpdCBmb3Igc2VuZGluZyBv dXQgdGhpcyBlbWFpbCBhZnRlciB0aGUgbWludXRlcyBvZiB0aGUgSUVURjgxLURIQyBzZXNzaW9u IGlzIHJlYWR5Lg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KTGVhZg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGRoY3dnLWJvdW5jZXNAaWV0 Zi5vcmcgW2RoY3dnLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTGVhZiB5ZWggW2xlYWYueS55ZWhA aHVhd2VpLmNvbV0NCreiy83KsbzkOiAyMDExxOo31MIyNsjVIDI6NDINCrW9OiBkaGN3Z0BpZXRm Lm9yZw0K1vfM4jogW2RoY3dnXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXll aC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wNS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wNS50eHQgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMZWFmIFllaCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJl Zml4LXBvb2wtb3B0DQpSZXZpc2lvbjogICAgICAgIDA1DQpUaXRsZTogICAgICAgICAgIFByZWZp eCBQb29sIE9wdGlvbiBmb3IgREhDUHY2IFJlbGF5IEFnZW50cyBvbiBQcm92aWRlciBFZGdlIFJv dXRlcnMNCkNyZWF0aW9uIGRhdGU6ICAgMjAxMS0wNy0yNQ0KV0cgSUQ6ICAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTMNCg0KQWJzdHJhY3Q6DQogICBU aGUgREhDUHY2IFByZWZpeCBQb29sIG9wdGlvbiBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgREhD UHY2IFByZWZpeA0KICAgRGVsZWdhdGlvbiAoREhDUHY2LVBEKSwgYWxsb3dpbmcgdGhlIERIQ1B2 NiBzZXJ2ZXIgdG8gbm90aWZ5IGEgREhDUHY2DQogICByZWxheSBhZ2VudCBpbXBsZW1lbnRlZCBv biBhIFByb3ZpZGVyIEVkZ2UgKFBFKSByb3V0ZXIgYWJvdXQgYWN0aXZlDQogICBwcmVmaXggcG9v bHMgYWxsb2NhdGVkIGJ5IHRoZSBESENQdjYgc2VydmVyIHRvIHRoZSBQRSByb3V0ZXIuICBUaGUN CiAgIGluZm9ybWF0aW9uIG9mIGFjdGl2ZSBwcmVmaXggcG9vbHMgY2FuIGJlIHVzZWQgdG8gZW5m b3JjZSBJUHY2IHJvdXRlDQogICBhZ2dyZWdhdGlvbiBvbiB0aGUgUEUgcm91dGVyIGJ5IGFkZGlu ZyBvciByZW1vdmluZyBhZ2dyZWdhdGVkIHJvdXRlcw0KICAgYWNjb3JkaW5nIHRvIHRoZSBzdGF0 dXMgb2YgdGhlIHByZWZpeCBwb29scy4gIFRoZSBhZHZlcnRpc2luZyBvZiB0aGUNCiAgIGFnZ3Jl Z2F0ZWQgcm91dGVzIGluIHRoZSByb3V0aW5nIHByb3RvY29sIGVuYWJsZWQgb24gdGhlIG5ldHdv cmstDQogICBmYWNpbmcgaW50ZXJmYWNlIG9mIFBFIHJvdXRlcnMgd2lsbCBkcmFtYXRpY2FsbHkg ZGVjcmVhc2VzIHRoZSBudW1iZXINCiAgIG9mIHRoZSByb3V0aW5nIHRhYmxlIGVudHJpZXMgaW4g dGhlIG5ldHdvcmsuDQoNCiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K --Boundary_(ID_ewrEZ9ypjii/tXp8RMlv0g) Content-id: <425F8660F42B08449DC9745C4D570F73@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Dear Group,

 

During IETF81 in Quebec city, the authors of draft-yeh-dhc-dhc= pv6-prefix-pool-opt updated it to be ver.-05, and presented the progress of= it in the DHC session (Pls. refer to 14-draft-yeh-dhc-dhcpv6-prefix-pool-opt-05).  You can also = find the log of changes in section 10 of this draft. Again 2= weeks after IETF81, the draft is still looking for your valuable comments feeding for the further discussion.

 

I wouldn't wait for sending out this email after the minu= tes of the IETF81-DHC session is ready.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org= [dhcwg-bounces@ietf.org] =B4=FA=B1=ED Leaf yeh [leaf.y.yeh@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C226=C8=D5 2:42
=B5=BD: dhcwg@ietf.org
=D6=F7=CC=E2: [dhcwg] New Version Notification for draft-yeh-dhc-dhc= pv6-prefix-pool-opt-05.txt

A new version of I-D, draft-yeh-dhc-dhcpv6-prefix-= pool-opt-05.txt has been successfully submitted by Leaf Yeh and posted to t= he IETF repository.

Filename:        draft-yeh-dhc-dhcpv6-pr= efix-pool-opt
Revision:        05
Title:           Prefix P= ool Option for DHCPv6 Relay Agents on Provider Edge Routers
Creation date:   2011-07-25
WG ID:           Individu= al Submission
Number of pages: 13

Abstract:
   The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 = Prefix
   Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a= DHCPv6
   relay agent implemented on a Provider Edge (PE) router about a= ctive
   prefix pools allocated by the DHCPv6 server to the PE router.&= nbsp; The
   information of active prefix pools can be used to enforce IPv6= route
   aggregation on the PE router by adding or removing aggregated = routes
   according to the status of the prefix pools.  The adverti= sing of the
   aggregated routes in the routing protocol enabled on the netwo= rk-
   facing interface of PE routers will dramatically decreases the= number
   of the routing table entries in the network.

 The IETF Secretariat
--Boundary_(ID_ewrEZ9ypjii/tXp8RMlv0g)-- From tomasz.mrugalski@gmail.com Mon Aug 15 14:30:51 2011 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 214CA21F8D1D for ; Mon, 15 Aug 2011 14:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.256 X-Spam-Level: X-Spam-Status: No, score=-4.256 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 GSNmZTEmFcwa for ; Mon, 15 Aug 2011 14:30:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E99621F8D1A for ; Mon, 15 Aug 2011 14:30:49 -0700 (PDT) Received: by wwf5 with SMTP id 5so3545772wwf.13 for ; Mon, 15 Aug 2011 14:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qj40dtIb1orHOP2llSXqrax/Xub8DaD4sRyOEH6W/NM=; b=PThqg+ZEAjZ4NWrSM0w6oUsf8qdgHZlcs/tTCHor+sxz9YnBVzvOUXYRpF3Vwso9LQ t2I3w1UKliIMLJN8NR4anSw5rJMmDzQgkbrTpnx6pZAjfMS+4PBnXczuxLUcd0GfF0sl hisnRZBsAOWYfhEsF6VQsOpjetRWapi2lkgJE= Received: by 10.216.68.72 with SMTP id k50mr2549589wed.102.1313443894557; Mon, 15 Aug 2011 14:31:34 -0700 (PDT) Received: from MacBook-Tomasz-Mrugalski.local (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id fn12sm4878969wbb.4.2011.08.15.14.31.20 (version=SSLv3 cipher=OTHER); Mon, 15 Aug 2011 14:31:21 -0700 (PDT) Message-ID: <4E499023.3030300@gmail.com> Date: Mon, 15 Aug 2011 23:31:15 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: DHC WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 failover meeting 2011-08-16 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 Aug 2011 21:30:51 -0000 Hi, Due to vacation season, work on failover is progressing slower than usual. Nevertheless, I'd like to continue this effort. Meeting schedule will be in flux till end of August. Regular, weekly meetings will resume by early September. Let me know if you have any preference regarding schedule. Agenda for tomorrow's meeting: - Partner update - Time skew - Sending data - Conflict resolution - Acknowledging reception - Endpoint states - State descriptions - Initializing FSM - State transitions - Failure recovery - partner-down event - network-partition event - Security Meeting invitation and updated design draft will be sent soon to anyone who expressed interest or participated in previous meetings. Tomek Please find necessary meeting information below: Topic: DHCPv6 Failover Date: Tuesday, August 16, 2011 Time: 10:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 804 574 300 Meeting Password: v6me ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://internetconsort.webex.com/internetconsort/j.php?ED=158985472&UID=491983767&PW=NNjA5ZDI0N2Q4&RT=MiM0 ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-877-669-3239 Call-in toll number (US/Canada): +1-408-600-3600 Global call-in numbers: https://internetconsort.webex.com/internetconsort/globalcallin.php?serviceType=MC&ED=158985472&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:804 574 300 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://internetconsort.webex.com/internetconsort/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://internetconsort.webex.com/internetconsort/j.php?ED=158985472&UID=491983767&ICS=MS&LD=1&RD=2&ST=1&SHA2=Z2iz206SYrt5erMHWaGksX8E-FaK6uRPqcWa0fVoitM= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://internetconsort.webex.com/internetconsort/systemdiagnosis.php. http://www.webex.com CCM:+14086003600x804574300# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. From internet-drafts@ietf.org Tue Aug 16 07:10:27 2011 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 AF45F21F8B10; Tue, 16 Aug 2011 07:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 NNGuNpZQ+kQM; Tue, 16 Aug 2011 07:10:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8B21F8B13; Tue, 16 Aug 2011 07:10:25 -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: 3.58 Message-ID: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2011 07:10:25 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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, 16 Aug 2011 14:10: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 Gr= oup of the IETF. Title : Client Identifier Option in DHCP Server Replies Author(s) : Narasimha Swamy Gaurav Halwasia Prashant Jhingran Filename : draft-ietf-dhc-client-id-01.txt Pages : 5 Date : 2011-08-16 This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' o= ption by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT= 9; return client identifier' option to the client. Requirements A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-client-id-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-client-id-01.txt From pjhingra@cisco.com Tue Aug 16 22:27:24 2011 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 48C5321F8834 for ; Tue, 16 Aug 2011 22:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 4u7hDa4UdMPx for ; Tue, 16 Aug 2011 22:27:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0D85E21F87C5 for ; Tue, 16 Aug 2011 22:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pjhingra@cisco.com; l=2059; q=dns/txt; s=iport; t=1313558893; x=1314768493; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=N9pb4QHxpU6nejNm+L3fkwox0jzNNgWmx4w6FUr+CoE=; b=eIYRbSfUiS10YBac2MGvXeWysnO7WCW5yu4XYIz53JksaQhbioitSHi6 93upD1H254LL08qSh5w9meA1bNPRMK7m/RsxMih25lEdhpTn+aDMlspvg UlKyMmtiAkTGbQNsrAwc7vXAlKrPzORgWFTNRlg3sWNNqMjlcZxlkjDOH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEBADdRS05Io8UR/2dsb2JhbABBmHxEjxF3gUABAQEBAwEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQLCAgBEgeHUppYAZ8rhWlfBIddkEqLaA X-IronPort-AV: E=Sophos;i="4.68,237,1312156800"; d="scan'208";a="111150151" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 17 Aug 2011 05:28:10 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7H5SAgd019005; Wed, 17 Aug 2011 05:28:10 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 10:58:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Aug 2011 10:58:08 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E24905EDA0D0@XMB-BGL-413.cisco.com> In-Reply-To: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt thread-index: AcxcHmcynu3qOL6GTcC0kRgBx116uwAfyKiQ References: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> From: "Prashant Jhingran (pjhingra)" To: X-OriginalArrivalTime: 17 Aug 2011 05:28:10.0279 (UTC) FILETIME=[73B5E370:01CC5C9E] Cc: narasimha.nelakuditi@nokia.com Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Wed, 17 Aug 2011 05:27:24 -0000 Hi all, An updated version of the draft-ietf-dhc-client-id-01 has been submitted to DHC WG for review. This draft attempts to highlight the problems faced and perspective solution when a DHCP client, not having a valid hardware address value to be filled in 'chaddr' field, may set this field as zero. The authors would like to know WG comments/views on this proposal so that we can take it forward. Many thanks in advance.=20 - Regards, Prashant Jhingran -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, August 16, 2011 7:40 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt 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 : Client Identifier Option in DHCP Server Replies Author(s) : Narasimha Swamy Gaurav Halwasia Prashant Jhingran Filename : draft-ietf-dhc-client-id-01.txt Pages : 5 Date : 2011-08-16 This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-client-id-01.txt=20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/=20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-client-id-01.txt=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Wed Aug 17 06:44:00 2011 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 9275D21F8B62 for ; Wed, 17 Aug 2011 06:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 2uJW-ubk-qNn for ; Wed, 17 Aug 2011 06:43:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 435ED21F8B25 for ; Wed, 17 Aug 2011 06:43:59 -0700 (PDT) Received: by wyg8 with SMTP id 8so774938wyg.31 for ; Wed, 17 Aug 2011 06:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lNmm4xd9EEw9bOSe7bO6BW7rkWstgyc2W+8crWV8C18=; b=IfMfFW3rGplC2ZZW356eZnxA97GTEVWpOu1CPTz0NkHJxt8L7x2jPshKbVQOfrRheX zYS/ZZD8Kj7w7WQGcPb7B5XR9W58G/H3FxDwINc8Ran5QbXKF6NU+zh/ZLH0toPeOJ0u 8rvyQibTylcXmH4uV96Dldkeh8O9xgz4x53xU= Received: by 10.227.57.209 with SMTP id d17mr861391wbh.94.1313588688698; Wed, 17 Aug 2011 06:44:48 -0700 (PDT) Received: from MacBook-Tomasz-Mrugalski.local (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id fd4sm929935wbb.13.2011.08.17.06.44.46 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 06:44:47 -0700 (PDT) Message-ID: <4E4BC5CD.8080700@gmail.com> Date: Wed, 17 Aug 2011 15:44:45 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: DHC WG References: <4E499023.3030300@gmail.com> In-Reply-To: <4E499023.3030300@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 failover meeting 2011-08-16 minutes, 2011-08-23 invitation 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 Aug 2011 13:44:00 -0000 2011-08-16 DHCPv6 Failover Meeting minutes Attendees: Kim Kinnear Shawn Routhier Tomek Mrugalski A brief summary of recent developments was given by Tomek. Tomek apologized for sending updated version of the draft shortly before the meeting, not earlier. There were no additional topics submitted, so we started working our way thru the agenda. We continued our discussion about design document from last meeting. First topic discussed was the problem of clock differences between partners. Shawn suggested that dependency on external mechanisms (like NTP) that may be not available, especially during network partition events is something that should be avoided. Kim proposed to reuse mechanism from v4: each packet contains a timestamp as seen by transmitting partner. Receiving partner stores its own timestamp during packet reception and compares it with content received within the packet. Calculated difference is then average along several recent packets. This value is called time skew and is used during all time related calculations. Kim noted that while such algorithm is deployable, there still may be occasional time differences. Therefore each time operation should not be calculated precisely, but rather using fuzzy comparison. I values are close enough to each other, they should be considered equal. Exact time resolution is to be determined, but current perception is that anything will less than 5 seconds difference should be treated as equal. Related topic of time format was discussed. Tomek pointed out that RFC3315 in Section 9.2 (definition of link-local+time-based DUID) specifies timestamps as number of seconds since January 1st 2000 modulo 2^32, so we may reuse that. Time differences should be specified as signed values to have the ability to express negative offset. Another point was about general transmission format between partners. Everyone agreed that we should try to reuse existing code if possible. Since transmission is done over TCP, failover will reuse framing format defined for bulk leasequery, just will define different message types. Regular DHCPv6 option formats will be used. The actual content of the lease update information to be exchanged between partners was discussed next. We agreed that it is too early to specify every bit of information as this belongs to protocol spec, not design document. We named several mandatory elements. Kim suggested that we should avoid specifying lease length the same way as was done in v4. In v4 different values of lease lifetime was sent to client and to partner. Kim referred to this as "lying to the partner". It was suggested that partners should send 2 values: requested by client and actual value assigned to client. Discussion about absolute vs relative times was discussed next. Kim said that it does not matter much. Tomek mentioned that absolute timestamps may be more difficult to read. Shawn said that known implementation have robust logging capabilities, so that is not a big problem. We agreed that there are no strong opinions on that and either way will be fine. The last topic discussed was conflict resolution. Different scenarios were mentioned: server receiving unknown lease, server receiving old state of lease while knowing better (newer) state etc. Kim suggested that section describing conflict resolution will be basically a flowchart that describes how to determine which lease is "better". We will continue discussion during next meeting. Tomek 2011-08-23 meeting details: ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: DHCPv6 Failover Date: Tuesday, August 23, 2011 Time: 10:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 802 178 764 Meeting Password: v6me ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://internetconsort.webex.com/internetconsort/j.php?ED=158985497&UID=491983767&PW=NMTk3N2MzMTMz&RT=MiM0 ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-877-669-3239 Call-in toll number (US/Canada): +1-408-600-3600 Global call-in numbers: https://internetconsort.webex.com/internetconsort/globalcallin.php?serviceType=MC&ED=158985497&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:802 178 764 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://internetconsort.webex.com/internetconsort/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://internetconsort.webex.com/internetconsort/j.php?ED=158985497&UID=491983767&ICS=MS&LD=1&RD=2&ST=1&SHA2=fDRkbEeFmwyysi7zbma2lTxpnZgVcfxQZO8V-oXAPus= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://internetconsort.webex.com/internetconsort/systemdiagnosis.php. http://www.webex.com CCM:+14086003600x802178764# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. From Ted.Lemon@nominum.com Wed Aug 17 08:33:19 2011 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 B12F921F8B3A for ; Wed, 17 Aug 2011 08:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 4qNFlLjEjHzC for ; Wed, 17 Aug 2011 08:33:19 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE221F859F for ; Wed, 17 Aug 2011 08:33:19 -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 DSNKTkvfa6WO1QyYlpF7wD1Dn9Hkyh7YzW9t@postini.com; Wed, 17 Aug 2011 08:34:10 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 A490AF8002 for ; Wed, 17 Aug 2011 08:34:03 -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 9C951190052; Wed, 17 Aug 2011 08:34:03 -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.01.0289.001; Wed, 17 Aug 2011 08:34:03 -0700 From: Ted Lemon To: "Prashant Jhingran (pjhingra)" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt Thread-Index: AQHMXB5iUZjUO1BYKEytJzb6fcRiZZUg+gAAgACpSgA= Date: Wed, 17 Aug 2011 15:34:03 +0000 Message-ID: <3B0BF2F4-6583-47A7-9B48-275F60F39908@nominum.com> References: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> <0C34754A9045B3419FB531A8C716E24905EDA0D0@XMB-BGL-413.cisco.com> In-Reply-To: <0C34754A9045B3419FB531A8C716E24905EDA0D0@XMB-BGL-413.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.225.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Wed, 17 Aug 2011 15:33:19 -0000 Just to clarify what's going on here, this document was a working group ite= m back in 2004, and has not been worked on since. The document clarifies = that the DHCP server has to return the client-identifier option if the clie= nt sent it; this is necessary in cases where the client does not have a val= ue to store in chaddr. I think this document makes sense, although I'm not sure that there is a re= al-world use case for it. I'm curious to know what motivated its revival= =97can you tell us why you're suddenly working on it again, Prashant? From volz@cisco.com Wed Aug 17 20:26:25 2011 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 8C63F21F886A for ; Wed, 17 Aug 2011 20:26:25 -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] 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 NE6b0bxnru5W for ; Wed, 17 Aug 2011 20:26:25 -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 EA81921F8839 for ; Wed, 17 Aug 2011 20:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1683; q=dns/txt; s=iport; t=1313638038; x=1314847638; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Mfot3GPqh5bQvySPrYYe7v2xhIbLSpw7NZBeWgNRfKE=; b=MxbtSyaocUhA3ODZR/YKpOI8v4TNB8p/dnbDoDY8fg474N9E4M0lGuvu hnQdJJs4brlxqXTcrLLh0mQjcdq/vmPGlygomxzZiJfeO8eoqFKtvDIs1 amVvY03q5rkDBh/m6JgwcRaFhKsfr53RpZ94jbmKv20FRJ3t1Wpphen8o 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAO6FTE6tJV2c/2dsb2JhbABBmRmPWHeBQAEBAQEDAQEBDwEdCjQDFAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah1KYBgGef4VpXwSHYJBIi34 X-IronPort-AV: E=Sophos;i="4.68,242,1312156800"; d="scan'208";a="14177735" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 18 Aug 2011 03:27:17 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7I3RHPj013798; Thu, 18 Aug 2011 03:27:17 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 22:27:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Aug 2011 22:27:16 -0500 Message-ID: In-Reply-To: <4E3C2DB2.2050103@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Quick review on thedraft-ietf-dhc-dhcpv6-reconfigure-rebind-07 Thread-Index: AcxTmF1PivjIdHVqTf+t06viEvYvnQJvdq3g References: <4E3C2DB2.2050103@gmail.com> From: "Bernie Volz (volz)" To: "Tomasz Mrugalski" , X-OriginalArrivalTime: 18 Aug 2011 03:27:16.0868 (UTC) FILETIME=[BAC0F440:01CC5D56] Subject: Re: [dhcwg] Quick review on thedraft-ietf-dhc-dhcpv6-reconfigure-rebind-07 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, 18 Aug 2011 03:26:25 -0000 I support this document as well. It will be useful when there is DHCPv6 failover ... what if the original server is the partner that is down. Both servers know the nonce (since they can exchange it in the binding updates) so the running partner can send a Reconfigure. But it would be useless to do this as the client will be sending Renew's with the downed failover partner's server-identifier option. (While the server's could also exchange their server-identifier option and "process" each other's packets, I think this is a bad idea. As is using the server-identifier for the failover pair.) - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomasz Mrugalski Sent: Friday, August 05, 2011 1:52 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Quick review on thedraft-ietf-dhc-dhcpv6-reconfigure-rebind-07 On 05.08.2011 15:25, Ted Lemon wrote: > On Aug 5, 2011, at 7:19 AM, Leaf yeh wrote: >> So the question is why the server definitely knows that it need to ask >> the client to get configuration from a different sever? >=20 > The server doesn't know. The server administrator knows that the > original server is down, and that the client must talk to a different > server. Another possibility is that such reconfigure event may be part of graceful server shutdown procedure. That would avoid RENEW flood for period between T1 and T2. Clients would immediately REBIND to new server. Oh, and by the way - I read and support this draft. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From pjhingra@cisco.com Wed Aug 17 22:28:26 2011 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 42B7E21F86AB for ; Wed, 17 Aug 2011 22:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Mgg2OI0MOenw for ; Wed, 17 Aug 2011 22:28:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0C21F863E for ; Wed, 17 Aug 2011 22:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pjhingra@cisco.com; l=1554; q=dns/txt; s=iport; t=1313645358; x=1314854958; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gLwUr4GLq2VAQ2C8dYR0RWqCf0jnAJIneAfMNCbYf48=; b=YIrNZV3IfCaoOAr5UAZZZq+vai2c1whCbNG/XXLJpWYcryj/cshMTRy0 PsrVxy9Q1LwaLCA/NJn8cIzLATRJH7wZn0Oj/0oE21nGCfazbaBh70jxB scbCl5RQWkeokjdU88mIPy9YSnoM7YwLYsc0lc5DYManhqIICvuTPD/a5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAAuiTE5Io8UQ/2dsb2JhbABAmRmPWXeBQAEBAQEDEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgCBAsICBMHoEoBnnqFaV8Eh16QSoto X-IronPort-AV: E=Sophos;i="4.68,243,1312156800"; d="scan'208";a="51003405" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 18 Aug 2011 05:29:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7I5StBc003613; Thu, 18 Aug 2011 05:29:16 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 10:59:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Aug 2011 10:59:11 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E24905EDA385@XMB-BGL-413.cisco.com> In-Reply-To: <3B0BF2F4-6583-47A7-9B48-275F60F39908@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt thread-index: AQHMXB5iUZjUO1BYKEytJzb6fcRiZZUg+gAAgACpSgCAACKlIA== References: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> <0C34754A9045B3419FB531A8C716E24905EDA0D0@XMB-BGL-413.cisco.com> <3B0BF2F4-6583-47A7-9B48-275F60F39908@nominum.com> From: "Prashant Jhingran (pjhingra)" To: "Ted Lemon" X-OriginalArrivalTime: 18 Aug 2011 05:29:12.0930 (UTC) FILETIME=[C3776C20:01CC5D67] Cc: dhcwg@ietf.org, narasimha.nelakuditi@nokia.com Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Thu, 18 Aug 2011 05:28:26 -0000 Hi Ted, We recently came across an issue where the client was indeed setting 'chaddr' as zero (hence there exist such clients) and as a result was unable to process the reply packets. Although there may be several workarounds, we thought of a solution which coincidentally was also suggested in draft-ietf-dhc-client-id-00 way back in 2004 and therefore we thought of collaboration. =20 The latest version incorporates the suggestions/comments made on -00 version of this draft and also highlights the issues faced by both relay agent and the client when 'chaddr' is set as zero. We appreciate your acknowledgement and we welcome comments from WG members on this draft. - Regards, Prashant Jhingran -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, August 17, 2011 9:04 PM To: Prashant Jhingran (pjhingra) Cc: ; Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt Just to clarify what's going on here, this document was a working group item back in 2004, and has not been worked on since. The document clarifies that the DHCP server has to return the client-identifier option if the client sent it; this is necessary in cases where the client does not have a value to store in chaddr. I think this document makes sense, although I'm not sure that there is a real-world use case for it. I'm curious to know what motivated its revival-can you tell us why you're suddenly working on it again, Prashant? From Ted.Lemon@nominum.com Thu Aug 18 06:06:20 2011 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 6345F21F8B46 for ; Thu, 18 Aug 2011 06:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CFByzh5V9Bop for ; Thu, 18 Aug 2011 06:06:19 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 96EAC21F8B42 for ; Thu, 18 Aug 2011 06:06:19 -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 DSNKTk0OgX0yl8ag7s9mepHZBggUKUs6mSRE@postini.com; Thu, 18 Aug 2011 06:07:13 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 E80FE1B8217 for ; Thu, 18 Aug 2011 06:07:12 -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 707F1190052; Thu, 18 Aug 2011 06:07:11 -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.01.0289.001; Thu, 18 Aug 2011 06:07:11 -0700 From: Ted Lemon To: "Prashant Jhingran (pjhingra)" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt Thread-Index: AQHMXB5iUZjUO1BYKEytJzb6fcRiZZUg+gAAgACpSgCAACKlIIABRqiA Date: Thu, 18 Aug 2011 13:07:11 +0000 Message-ID: <865DD526-6BA7-4DC9-A485-2DE1430A289A@nominum.com> References: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> <0C34754A9045B3419FB531A8C716E24905EDA0D0@XMB-BGL-413.cisco.com> <3B0BF2F4-6583-47A7-9B48-275F60F39908@nominum.com> <0C34754A9045B3419FB531A8C716E24905EDA385@XMB-BGL-413.cisco.com> In-Reply-To: <0C34754A9045B3419FB531A8C716E24905EDA385@XMB-BGL-413.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.52.29] Content-Type: multipart/alternative; boundary="_000_865DD5266BA74DC9A4852DE1430A289Anominumcom_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Thu, 18 Aug 2011 13:06:20 -0000 --_000_865DD5266BA74DC9A4852DE1430A289Anominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 17, 2011, at 10:29 PM, Prashant Jhingran (pjhingra) wrote: We recently came across an issue where the client was indeed setting 'chaddr' as zero (hence there exist such clients) and as a result was unable to process the reply packets. Although there may be several workarounds, we thought of a solution which coincidentally was also suggested in draft-ietf-dhc-client-id-00 way back in 2004 and therefore we thought of collaboration. Was the client broken, or using a link layer that doesn't support clients h= aving link-layer addresses? --_000_865DD5266BA74DC9A4852DE1430A289Anominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8332B2A28B11874B8538D3DA9ACAA340@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 17, 2011, at 10:29 PM, Prashant Jhingran (pjhingra) wrote:
We recently came across an issue where the client was indeed setting
'chaddr' as zero (hence there exist such clients) and as a result was
unable to process the reply packets. Although there may be several
workarounds, we thought of a solution which coincidentally was also
suggested in draft-ietf-dhc-client-id-00 way back in 2004 and therefore
we thought of collaboration.  

Was the client broken, or using a link layer that doesn't support clie= nts having link-layer addresses?

--_000_865DD5266BA74DC9A4852DE1430A289Anominumcom_-- From volz@cisco.com Wed Aug 17 20:18:42 2011 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 1888021F87D6 for ; Wed, 17 Aug 2011 20:18:42 -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] 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 1dJp2LMD5F-u for ; Wed, 17 Aug 2011 20:18:41 -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 4D57721F87C9 for ; Wed, 17 Aug 2011 20:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=2847; q=dns/txt; s=iport; t=1313637574; x=1314847174; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=W22KPU1TuZtWj+g7/FNlJmqZCU/WPAce7tmv1Pjzmy4=; b=SAe21fWVCsMN/MzPVNrbcqDRQDFkp8//tDA59E5H4tq3fOlF3qawwluB GB504SrMOSp2UAle9P7x3l+FrIjC5oUz9d/H2DeY3g8/yrjMl8IRZLcSW 4Ni5L52lk+3nGn2EdUnNzo0wN231KDNv7cN04tHXkOkRuAreCj7MSDkjG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAE6ETE6tJXG+/2dsb2JhbAAnGpkZj1h3gTkHAQEBAQMBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEgBh8JCAEBBAESCBqHUiOXfAGef4VpXwSHYJBIhGGHHUs X-IronPort-AV: E=Sophos;i="4.68,242,1312156800"; d="scan'208";a="14177144" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 Aug 2011 03:19:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7I3JXqw016254; Thu, 18 Aug 2011 03:19:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 22:19:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Aug 2011 22:19:32 -0500 Message-ID: In-Reply-To: <20110809144902.3DF1398C51C@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] [Technical Errata Reported] RFC3315 (2928) Thread-Index: AcxZAZJtusoNB4FqT5CmS+2ka+YBLAEU8irw References: <20110809144902.3DF1398C51C@rfc-editor.org> From: "Bernie Volz (volz)" To: "RFC Errata System" , , , , , , , , , X-OriginalArrivalTime: 18 Aug 2011 03:19:33.0810 (UTC) FILETIME=[A6BFE920:01CC5D55] X-Mailman-Approved-At: Thu, 18 Aug 2011 20:59:39 -0700 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [Technical Errata Reported] RFC3315 (2928) 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, 18 Aug 2011 03:18:42 -0000 This errata can be accepted or is 'verified as valid'. I really don't understand the instructions: >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. Perhaps it meant to say "is verified or should be rejected"? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Tuesday, August 09, 2011 10:49 AM To: Jim.Bound@hp.com; volz@metrocast.net; Ted.Lemon@nominum.com; charles.perkins@nokia.com; michael.carney@sun.com; rdroms.ietf@gmail.com; jari.arkko@piuha.net; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com Cc: dhcwg@ietf.org; rfc-editor@rfc-editor.org Subject: [dhcwg] [Technical Errata Reported] RFC3315 (2928) The following errata report has been submitted for RFC3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D3315&eid=3D2928 -------------------------------------- Type: Technical Reported by: Leaf Yeh Section: 17.2.1 Original Text ------------- For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message. Corrected Text -------------- For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option (see section 22.20) in the Solicit message, the servers discard the Solicit message. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC3315 (draft-ietf-dhc-dhcpv6-28) -------------------------------------- Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Publication Date : July 2003 Author(s) : R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Thu Aug 18 21:31:50 2011 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 A097821F86AF for ; Thu, 18 Aug 2011 21:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=2.016, 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 nRasyYkKxmIS for ; Thu, 18 Aug 2011 21:31:49 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 870AB21F8661 for ; Thu, 18 Aug 2011 21:31:49 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ500EBURAJGD@szxga05-in.huawei.com> for dhcwg@ietf.org; Fri, 19 Aug 2011 12:32:43 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ5003SARAGR5@szxga05-in.huawei.com> for dhcwg@ietf.org; Fri, 19 Aug 2011 12:32:43 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG16638; Fri, 19 Aug 2011 12:32:38 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 12:32:32 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.116]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 12:32:38 +0800 Date: Fri, 19 Aug 2011 04:32:37 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.86] To: "Bernie Volz (volz)" , RFC Errata System Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] [Technical Errata Reported] RFC3315 (2928) Thread-index: AQHMVqN+z9H6hLiR7UqqJdqgfcJ1G5Uhd+gAgAIp7OA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110809144902.3DF1398C51C@rfc-editor.org> X-Mailman-Approved-At: Sat, 20 Aug 2011 05:48:17 -0700 Cc: "Jim.Bound@hp.com" , "michael.carney@sun.com" , "ted.lemon@nominum.com" , "charles.perkins@nokia.com" , "dhcwg@ietf.org" , "volz@metrocast.net" , "rdroms.ietf@gmail.com" Subject: Re: [dhcwg] [Technical Errata Reported] RFC3315 (2928) 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 Aug 2011 04:31:50 -0000 All of 8 Erratum on the Errata page of RFC3315 (http://www.rfc-editor.org/errata_search.php?rfc=3315) are in the status of 'Reported'. Some of them were reported in the middle of 2006. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Thursday, August 18, 2011 11:20 AM To: RFC Errata System; Jim.Bound@hp.com; volz@metrocast.net; Ted.Lemon@nominum.com; charles.perkins@nokia.com; michael.carney@sun.com; rdroms.ietf@gmail.com; jari.arkko@piuha.net; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [Technical Errata Reported] RFC3315 (2928) This errata can be accepted or is 'verified as valid'. I really don't understand the instructions: >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. Perhaps it meant to say "is verified or should be rejected"? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Tuesday, August 09, 2011 10:49 AM To: Jim.Bound@hp.com; volz@metrocast.net; Ted.Lemon@nominum.com; charles.perkins@nokia.com; michael.carney@sun.com; rdroms.ietf@gmail.com; jari.arkko@piuha.net; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com Cc: dhcwg@ietf.org; rfc-editor@rfc-editor.org Subject: [dhcwg] [Technical Errata Reported] RFC3315 (2928) The following errata report has been submitted for RFC3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3315&eid=2928 -------------------------------------- Type: Technical Reported by: Leaf Yeh Section: 17.2.1 Original Text ------------- For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message. Corrected Text -------------- For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option (see section 22.20) in the Solicit message, the servers discard the Solicit message. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3315 (draft-ietf-dhc-dhcpv6-28) -------------------------------------- Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Publication Date : July 2003 Author(s) : R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Mon Aug 22 00:37:03 2011 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 21D2A21F8906; Mon, 22 Aug 2011 00:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 HPpCZ0m88nKb; Mon, 22 Aug 2011 00:37:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A369B21F8880; Mon, 22 Aug 2011 00:37:02 -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: 3.59 Message-ID: <20110822073702.1451.53326.idtracker@ietfa.amsl.com> Date: Mon, 22 Aug 2011 00:37:02 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-reconfigure-rebind-08.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, 22 Aug 2011 07:37:03 -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 Gr= oup of the IETF. Title : Rebind Capability in DHCPv6 Reconfigure Messages Author(s) : D. R. Evans Ralph Droms Sheng Jiang Filename : draft-ietf-dhc-dhcpv6-reconfigure-rebind-08.txt Pages : 8 Date : 2011-08-22 This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebin= d-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind= -08.txt From leaf.y.yeh@huawei.com Mon Aug 22 03:10:15 2011 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 7D2DB21F84ED for ; Mon, 22 Aug 2011 03:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.674 X-Spam-Level: X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=1.924, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 afBKohi-ael0 for ; Mon, 22 Aug 2011 03:10:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4621F8B0A for ; Mon, 22 Aug 2011 03:10:14 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB009R5QYJ51@szxga05-in.huawei.com> for dhcwg@ietf.org; Mon, 22 Aug 2011 18:11:07 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQB00ERMQY6X4@szxga05-in.huawei.com> for dhcwg@ietf.org; Mon, 22 Aug 2011 18:11:07 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH86361; Mon, 22 Aug 2011 18:11:05 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 22 Aug 2011 18:11:03 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.116]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Mon, 22 Aug 2011 18:11:03 +0800 Date: Mon, 22 Aug 2011 10:11:03 +0000 From: Leaf yeh In-reply-to: <952C7031-7E6B-4D97-8016-3B9BAB9A9162@mimectl> X-Originating-IP: [10.70.39.86] To: "dhcwg@ietf.org" , "rajiva@cisco.com" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3TYBxFzAXByTaxPw6/VzAg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-05.txt Thread-index: AQHMSv2XEGXzHtFi+Uu3WBWbJ98yDpUeKBTRgAAOheeACnjuoA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110725170304.18652.99891.idtracker@ietfa.amsl.com> <952C7031-7E6B-4D97-8016-3B9BAB9A9162@mimectl> Cc: Juergen Schoenwaelder , "huj@ctbri.com.cn" , Tina TSOU Subject: Re: [dhcwg] New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-05.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, 22 Aug 2011 10:10:15 -0000 --Boundary_(ID_3TYBxFzAXByTaxPw6/VzAg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SXMgdGhlcmUgYW55IG9uZSBpbiBESEMgd2hvIGZlZWxzIGFueSBvZiB0aGUgdW5jb21mb3J0YWJs ZSBvbiB0aGlzIGRyYWZ0IChkcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHQtMDUp ID8NCklmIHNvbWVvbmUgZG9lcywgY291bGQgeW91IHNoYXJlIHRoZSByZWFzb24gdG8gdXM/IFRo ZSBhdXRob3JzIHdpbGwgYXBwcmVjaWF0ZSBvbiB0aGF0Lg0KVGhlbiB3ZSBjb3VsZCBrbm93IGhv dyB0byBnbyBmb3IgdGhlIG5leHQgc3RlcCBvZiB0aGlzIGRyYWZ0Lg0KDQoNCkJlc3QgUmVnYXJk cywNCkxlYWYNCg0KDQpGcm9tOiBMZWFmIHllaA0KU2VudDogVHVlc2RheSwgQXVndXN0IDE2LCAy MDExIDEyOjEzIEFNDQpUbzogZGhjd2dAaWV0Zi5vcmcNCkNjOiBkcmFmdC15ZWgtZGhjLWRoY3B2 Ni1wcmVmaXgtcG9vbC1vcHRAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGhjd2ddIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJlZml4LXBv b2wtb3B0LTA1LnR4dA0KDQoNCkRlYXIgR3JvdXAsDQoNCg0KDQpEdXJpbmcgSUVURjgxIGluIFF1 ZWJlYyBjaXR5LCB0aGUgYXV0aG9ycyBvZiBkcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9v bC1vcHQgdXBkYXRlZCBpdCB0byBiZSB2ZXIuLTA1LCBhbmQgcHJlc2VudGVkIHRoZSBwcm9ncmVz cyBvZiBpdCBpbiB0aGUgREhDIHNlc3Npb24gKFBscy4gcmVmZXIgdG8gMTQtZHJhZnQteWVoLWRo Yy1kaGNwdjYtcHJlZml4LXBvb2wtb3B0LTA1PGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvODEvc2xpZGVzL2RoYy0yLnBkZj4pLiAgWW91IGNhbiBhbHNvIGZpbmQgdGhlIGxvZyBvZiBj aGFuZ2VzIGluIHNlY3Rpb24gMTAgb2YgdGhpcyBkcmFmdC4gQWdhaW4gMiB3ZWVrcyBhZnRlciBJ RVRGODEsIHRoZSBkcmFmdCBpcyBzdGlsbCBsb29raW5nIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1l bnRzIGZlZWRpbmcgZm9yIHRoZSBmdXJ0aGVyIGRpc2N1c3Npb24uDQoNCg0KDQpJIHdvdWxkbid0 IHdhaXQgZm9yIHNlbmRpbmcgb3V0IHRoaXMgZW1haWwgYWZ0ZXIgdGhlIG1pbnV0ZXMgb2YgdGhl IElFVEY4MS1ESEMgc2Vzc2lvbiBpcyByZWFkeS4NCg0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoN CkxlYWYNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu2 5Lq6OiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFtkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggTGVhZiB5ZWggW2xlYWYueS55ZWhAaHVhd2VpLmNvbV0NCuWPkemAgeaXtumXtDogMjAxMeW5 tDfmnIgyNuaXpSAyOjQyDQrliLA6IGRoY3dnQGlldGYub3JnDQrkuLvpopg6IFtkaGN3Z10gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9v bC1vcHQtMDUudHh0DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteWVoLWRoYy1kaGNwdjYt cHJlZml4LXBvb2wtb3B0LTA1LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IExlYWYgWWVoIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 ICAgICAgICBkcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHQNClJldmlzaW9uOiAg ICAgICAgMDUNClRpdGxlOiAgICAgICAgICAgUHJlZml4IFBvb2wgT3B0aW9uIGZvciBESENQdjYg UmVsYXkgQWdlbnRzIG9uIFByb3ZpZGVyIEVkZ2UgUm91dGVycw0KQ3JlYXRpb24gZGF0ZTogICAy MDExLTA3LTI1DQpXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVy IG9mIHBhZ2VzOiAxMw0KDQpBYnN0cmFjdDoNCiAgIFRoZSBESENQdjYgUHJlZml4IFBvb2wgb3B0 aW9uIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBESENQdjYgUHJlZml4DQogICBEZWxlZ2F0aW9u IChESENQdjYtUEQpLCBhbGxvd2luZyB0aGUgREhDUHY2IHNlcnZlciB0byBub3RpZnkgYSBESENQ djYNCiAgIHJlbGF5IGFnZW50IGltcGxlbWVudGVkIG9uIGEgUHJvdmlkZXIgRWRnZSAoUEUpIHJv dXRlciBhYm91dCBhY3RpdmUNCiAgIHByZWZpeCBwb29scyBhbGxvY2F0ZWQgYnkgdGhlIERIQ1B2 NiBzZXJ2ZXIgdG8gdGhlIFBFIHJvdXRlci4gIFRoZQ0KICAgaW5mb3JtYXRpb24gb2YgYWN0aXZl IHByZWZpeCBwb29scyBjYW4gYmUgdXNlZCB0byBlbmZvcmNlIElQdjYgcm91dGUNCiAgIGFnZ3Jl Z2F0aW9uIG9uIHRoZSBQRSByb3V0ZXIgYnkgYWRkaW5nIG9yIHJlbW92aW5nIGFnZ3JlZ2F0ZWQg cm91dGVzDQogICBhY2NvcmRpbmcgdG8gdGhlIHN0YXR1cyBvZiB0aGUgcHJlZml4IHBvb2xzLiAg VGhlIGFkdmVydGlzaW5nIG9mIHRoZQ0KICAgYWdncmVnYXRlZCByb3V0ZXMgaW4gdGhlIHJvdXRp bmcgcHJvdG9jb2wgZW5hYmxlZCBvbiB0aGUgbmV0d29yay0NCiAgIGZhY2luZyBpbnRlcmZhY2Ug b2YgUEUgcm91dGVycyB3aWxsIGRyYW1hdGljYWxseSBkZWNyZWFzZXMgdGhlIG51bWJlcg0KICAg b2YgdGhlIHJvdXRpbmcgdGFibGUgZW50cmllcyBpbiB0aGUgbmV0d29yay4NCg0KIFRoZSBJRVRG IFNlY3JldGFyaWF0DQo= --Boundary_(ID_3TYBxFzAXByTaxPw6/VzAg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGUgaWQ9b3dhUGFyYVN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVs dCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN TCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9u cyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgi Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuZW1haWxxdW90ZSwgbGkuZW1haWxxdW90 ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxxdW90ZTsNCgltYXJnaW4t dG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdp bi1sZWZ0OjEuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglib3JkZXI6bm9uZTsNCglw YWRkaW5nOjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPklzIHRoZXJlIGFueSBvbmUgaW4gREhDIHdobyBmZWVscyBhbnkgb2YgdGhlIHVu Y29tZm9ydGFibGUgb24gdGhpcyBkcmFmdCAoZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJlZml4LXBv b2wtb3B0LTA1KSA/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklmIHNvbWVvbmUgZG9lcywgY291bGQgeW91IHNoYXJlIHRoZSByZWFzb24gdG8gdXM/IFRoZSBh dXRob3JzIHdpbGwgYXBwcmVjaWF0ZSBvbiB0aGF0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGVuIHdlIGNvdWxkIGtub3cgaG93IHRvIGdvIGZvciB0aGUg bmV4dCBzdGVwIG9mIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVz dCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGVh ZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTGVh ZiB5ZWgNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTEgMTI6MTMg QU08YnI+DQo8Yj5Ubzo8L2I+IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC15 ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHRAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtkaGN3Z10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15 ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHQtMDUudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIEdyb3VwLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EdXJpbmcmbmJzcDtJ RVRGODEgaW4gUXVlYmVjIGNpdHksIHRoZSBhdXRob3JzIG9mJm5ic3A7ZHJhZnQteWVoLWRoYy1k aGNwdjYtcHJlZml4LXBvb2wtb3B0IHVwZGF0ZWQgaXQgdG8gYmUgdmVyLi0wNSwgYW5kIHByZXNl bnRlZCB0aGUgcHJvZ3Jlc3Mgb2YgaXQgaW4gdGhlIERIQyBzZXNzaW9uIChQbHMuDQogcmVmZXIg dG8gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvZGhj LTIucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQoxNC1kcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgt cG9vbC1vcHQtMDU8L2E+KS4mbmJzcDsgWW91IGNhbiBhbHNvIGZpbmQgdGhlJm5ic3A7bG9nIG9m IGNoYW5nZXMgaW4mbmJzcDtzZWN0aW9uIDEwIG9mIHRoaXMgZHJhZnQuIEFnYWluJm5ic3A7MiB3 ZWVrcyZuYnNwO2FmdGVyIElFVEY4MSwmbmJzcDt0aGUgZHJhZnQgaXMgc3RpbGwgbG9va2luZyBm b3IgeW91ciB2YWx1YWJsZSBjb21tZW50cyBmZWVkaW5nIGZvciB0aGUgZnVydGhlciBkaXNjdXNz aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkkmbmJzcDt3b3VsZG4ndCZuYnNwO3dhaXQmbmJzcDtmb3Igc2VuZGluZyBvdXQgdGhpcyBlbWFp bCBhZnRlciB0aGUgbWludXRlcyBvZiB0aGUgSUVURjgxLURIQyBzZXNzaW9uIGlzIHJlYWR5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkxlYWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEw MCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBGNDg2ODgz Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPuWPkeS7tuS6ujwvc3Bh bj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPg0KIGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW2RoY3dnLWJvdW5jZXNAaWV0 Zi5vcmddIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ 5Luj6KGoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+IExlYWYgeWVoIFtsZWFmLnkueWVoQGh1YXdlaS5jb21dPGJyPg0KPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7lj5HpgIHml7bpl7Q8 L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4NCiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj43PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4yNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQogMjo0Mjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+5YiwPC9zcGFuPjwvYj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQog ZGhjd2dAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KIFtkaGN3Z10gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1v cHQtMDUudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15ZWgtZGhj LWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHQtMDUudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgTGVhZiBZZWggYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4N Cjxicj4NCkZpbGVuYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHQ8YnI+DQpSZXZpc2lvbjombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDU8YnI+DQpUaXRsZTombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UHJlZml4IFBvb2wgT3B0aW9uIGZvciBESENQdjYgUmVsYXkgQWdlbnRzIG9uIFByb3ZpZGVyIEVk Z2UgUm91dGVyczxicj4NCkNyZWF0aW9uIGRhdGU6Jm5ic3A7Jm5ic3A7IDIwMTEtMDctMjU8YnI+ DQpXRyBJRDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAx Mzxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyZuYnNwOyBUaGUgREhDUHY2IFByZWZp eCBQb29sIG9wdGlvbiBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgREhDUHY2IFByZWZpeDxicj4N CiZuYnNwOyZuYnNwOyBEZWxlZ2F0aW9uIChESENQdjYtUEQpLCBhbGxvd2luZyB0aGUgREhDUHY2 IHNlcnZlciB0byBub3RpZnkgYSBESENQdjY8YnI+DQombmJzcDsmbmJzcDsgcmVsYXkgYWdlbnQg aW1wbGVtZW50ZWQgb24gYSBQcm92aWRlciBFZGdlIChQRSkgcm91dGVyIGFib3V0IGFjdGl2ZTxi cj4NCiZuYnNwOyZuYnNwOyBwcmVmaXggcG9vbHMgYWxsb2NhdGVkIGJ5IHRoZSBESENQdjYgc2Vy dmVyIHRvIHRoZSBQRSByb3V0ZXIuJm5ic3A7IFRoZTxicj4NCiZuYnNwOyZuYnNwOyBpbmZvcm1h dGlvbiBvZiBhY3RpdmUgcHJlZml4IHBvb2xzIGNhbiBiZSB1c2VkIHRvIGVuZm9yY2UgSVB2NiBy b3V0ZTxicj4NCiZuYnNwOyZuYnNwOyBhZ2dyZWdhdGlvbiBvbiB0aGUgUEUgcm91dGVyIGJ5IGFk ZGluZyBvciByZW1vdmluZyBhZ2dyZWdhdGVkIHJvdXRlczxicj4NCiZuYnNwOyZuYnNwOyBhY2Nv cmRpbmcgdG8gdGhlIHN0YXR1cyBvZiB0aGUgcHJlZml4IHBvb2xzLiZuYnNwOyBUaGUgYWR2ZXJ0 aXNpbmcgb2YgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7IGFnZ3JlZ2F0ZWQgcm91dGVzIGluIHRoZSBy b3V0aW5nIHByb3RvY29sIGVuYWJsZWQgb24gdGhlIG5ldHdvcmstPGJyPg0KJm5ic3A7Jm5ic3A7 IGZhY2luZyBpbnRlcmZhY2Ugb2YgUEUgcm91dGVycyB3aWxsIGRyYW1hdGljYWxseSBkZWNyZWFz ZXMgdGhlIG51bWJlcjxicj4NCiZuYnNwOyZuYnNwOyBvZiB0aGUgcm91dGluZyB0YWJsZSBlbnRy aWVzIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCiZuYnNwO1RoZSBJRVRGIFNlY3JldGFyaWF0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --Boundary_(ID_3TYBxFzAXByTaxPw6/VzAg)-- From pjhingra@cisco.com Wed Aug 24 01:26:31 2011 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 0567621F8AF8 for ; Wed, 24 Aug 2011 01:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 WacFCn0sTYjf for ; Wed, 24 Aug 2011 01:26:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F07AF21F8AF7 for ; Wed, 24 Aug 2011 01:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pjhingra@cisco.com; l=10293; q=dns/txt; s=iport; t=1314174459; x=1315384059; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=8ABj/YURKksVhfnTeNRIsY663ilnTVMquSuVeiPYJcQ=; b=QXQkC6EDjGCaA5Jtz5wlwKQPTPW8r0mKmcW3cenTF0bv+oaDBVW4LlGx v4n9mOXkKm7JaEOen85kBY0QSCOzgBUY4F/3CZVQ7abN8cpoRklt2LtkO leyKlzD6rJ8ZWwNCZJOf+jCulcxJF/J+5AgllFDeUp935cv0gkdZlQJ3A Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAANC0VE5Io8US/2dsb2JhbABCgk2VTY9Yd4FAAQEBAQMSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAIECwgIEwejBwGfMYVqXwSHX5BQi20 X-IronPort-AV: E=Sophos;i="4.68,274,1312156800"; d="scan'208,217";a="112197337" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2011 08:27:33 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7O8RXgQ015659; Wed, 24 Aug 2011 08:27:33 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 13:57:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6237.AB737FD3" Date: Wed, 24 Aug 2011 13:57:31 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E24905FE86AD@XMB-BGL-413.cisco.com> In-Reply-To: <865DD526-6BA7-4DC9-A485-2DE1430A289A@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt thread-index: AQHMXB5iUZjUO1BYKEytJzb6fcRiZZUg+gAAgACpSgCAACKlIIABRqiAgAimwSA= References: <20110816141025.10052.68904.idtracker@ietfa.amsl.com> <0C34754A9045B3419FB531A8C716E24905EDA0D0@XMB-BGL-413.cisco.com> <3B0BF2F4-6583-47A7-9B48-275F60F39908@nominum.com> <0C34754A9045B3419FB531A8C716E24905EDA385@XMB-BGL-413.cisco.com> <865DD526-6BA7-4DC9-A485-2DE1430A289A@nominum.com> From: "Prashant Jhingran (pjhingra)" To: "Ted Lemon" X-OriginalArrivalTime: 24 Aug 2011 08:27:33.0052 (UTC) FILETIME=[ABB6F7C0:01CC6237] Cc: dhcwg@ietf.org, narasimha.nelakuditi@nokia.com Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Wed, 24 Aug 2011 08:26:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6237.AB737FD3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, =20 Sorry for the delay in response, was travelling.=20 =20 This may not necessary happen in case of broken clients. This may happen when dhcp client is a base station *or* when the client is connected via interfaces like multilink PPP etc, which has no MAC address. So we can expect 'chaddr' as zero in certain networks. Pls let me know your thoughts, thanks in adv. =20 - Regards, Prashant Jhingran =20 =20 From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, August 18, 2011 6:37 PM To: Prashant Jhingran (pjhingra) Cc: ; ; Gaurav Halwasia (ghalwasi) Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-client-id-01.txt =20 On Aug 17, 2011, at 10:29 PM, Prashant Jhingran (pjhingra) wrote: We recently came across an issue where the client was indeed setting 'chaddr' as zero (hence there exist such clients) and as a result was unable to process the reply packets. Although there may be several workarounds, we thought of a solution which coincidentally was also suggested in draft-ietf-dhc-client-id-00 way back in 2004 and therefore we thought of collaboration. =20 =20 Was the client broken, or using a link layer that doesn't support clients having link-layer addresses? =20 ------_=_NextPart_001_01CC6237.AB737FD3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted,

 

Sorry for the delay in response, was travelling. =

 

This may not necessary happen in case of broken clients. This may = happen when dhcp client is a base station *or* when the client is = connected via interfaces like multilink PPP etc, which has no MAC = address. So we can expect ‘chaddr’ as zero in certain = networks. Pls let me know your thoughts, thanks in = adv.

 

-

Regards,

Prashant = Jhingran

 

 

From:= = Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Thursday, = August 18, 2011 6:37 PM
To: Prashant Jhingran = (pjhingra)
Cc: <dhcwg@ietf.org>; = <narasimha.nelakuditi@nokia.com>; Gaurav Halwasia = (ghalwasi)
Subject: Re: [dhcwg] I-D Action: = draft-ietf-dhc-client-id-01.txt

 

On = Aug 17, 2011, at 10:29 PM, Prashant Jhingran (pjhingra) = wrote:

We = recently came across an issue where the client was indeed = setting
'chaddr' as zero (hence there exist such = clients) and as a result was
unable to process the reply packets. Although = there may be several
workarounds, we thought of a solution which = coincidentally was also
suggested in draft-ietf-dhc-client-id-00 way = back in 2004 and therefore
we = thought of collaboration. =  

 

Was the = client broken, or using a link layer that doesn't support clients having = link-layer addresses?

 

------_=_NextPart_001_01CC6237.AB737FD3--