From gvithal@gmail.com Mon Apr 1 11:59:45 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2051B21F91CF for ; Mon, 1 Apr 2013 11:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIB+0-EBT8m8 for ; Mon, 1 Apr 2013 11:59:44 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC9D21F90B3 for ; Mon, 1 Apr 2013 11:59:44 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf10so2707847vcb.1 for ; Mon, 01 Apr 2013 11:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=koFDKYh2qcguZah4zsXw35ZAUGm1mU49nkAf+gqDMEU=; b=IbeKVqLL0LStopfwjLN6uNCXuqhuxtvOfkebVNBiR4MjwFyLDSU5kiqwbY5CFdRamb XTR21ZtOlL6nvCWjvUeyBJi3epbTQu6KzW8klzrJqKByUFJcuwYriz8osBn8LgiEMHST 6ikkYaJT8zEqRQ1yYoOKJAo0agGY94DrCkJHqCpgouGDlJ380sU2RjQtewTTHYdAUWW0 b8LU7rXYgSdrkvH0BSidb+RxpuUKIs15ppd9+Yg6AtiboKzJUqizdVEDup0EeM5Uiy+K dzfmuUJgc6THdDnKsag6vics40GSiUhHRe2Kl/JdfrUqVXLj6ZSM+ogrG3lv5abIhRwY CyWw== MIME-Version: 1.0 X-Received: by 10.220.109.210 with SMTP id k18mr10224627vcp.72.1364842784041; Mon, 01 Apr 2013 11:59:44 -0700 (PDT) Received: by 10.58.147.39 with HTTP; Mon, 1 Apr 2013 11:59:43 -0700 (PDT) Date: Tue, 2 Apr 2013 00:29:43 +0530 Message-ID: From: VithalPrasad Gaitonde To: "" Content-Type: multipart/alternative; boundary=047d7b3a98e65133ba04d951390d Subject: [dhcwg] DHCP in virtualized networks/Multi-tenant DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:59:45 -0000 --047d7b3a98e65133ba04d951390d Content-Type: text/plain; charset=ISO-8859-1 Is there any guidance (BCP ?) on using DHCP in network virtualization environments. Alternatively, is there interest in the working group on arriving at a guidance if there isn't one already. Thanks, Prasad --047d7b3a98e65133ba04d951390d Content-Type: text/html; charset=ISO-8859-1
Is there any guidance (BCP ?) on using DHCP in network virtualization environments. Alternatively, is there interest in the working group on arriving at a guidance if there isn't one already.

Thanks,
Prasad
--047d7b3a98e65133ba04d951390d-- From akostur@incognito.com Mon Apr 1 12:09:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5EC11E80EA for ; Mon, 1 Apr 2013 12:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-AXDpd4DEAo for ; Mon, 1 Apr 2013 12:09:12 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 7E30E11E80E9 for ; Mon, 1 Apr 2013 12:09:12 -0700 (PDT) Received: from mail-vc0-f199.google.com ([209.85.220.199]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUVnbWPVAfPKOdVAzeuIaPavUQfDfgol7@postini.com; Mon, 01 Apr 2013 12:09:12 PDT Received: by mail-vc0-f199.google.com with SMTP id ha11so5268544vcb.6 for ; Mon, 01 Apr 2013 12:09:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Mdh4IjSUGV18slpDRtiTw/6nyyx+PU+0JM+cHCb6AM4=; b=aIPibgH9qh5d3/A+VhQmK1/G0EtxmYP7mJc/JP8DFW3a7uYH6Gyn2M294iETmtOxRD KYNRewrrW3O4EpSFR2BnVKz4hjDgahc+Okc2mnpVCBcHPfIf6mjH9aG6v49beho3v5sY btAQnoRuNimHqAUH2TZQ6Qpzh02X2UriELMDYdKaf+MoHHMRPDJVZ4vzVGs6ccT9hfd/ zjZDsaRi+wPhExmaLT1lyaqut2LrJh+fv902PDMYPY3BfpAybxDgtuhvGKSyW3JI1nD/ DqC3JB59g9HEDCElU3fwFg/9zUMNue3Z9DfWpEOQ7ZBmLfl+XkRwl2pdF5VMsK1Y4Apr d0XA== X-Received: by 10.220.109.145 with SMTP id j17mr10181172vcp.34.1364843351541; Mon, 01 Apr 2013 12:09:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.109.145 with SMTP id j17mr10181153vcp.34.1364843351179; Mon, 01 Apr 2013 12:09:11 -0700 (PDT) Received: by 10.220.144.211 with HTTP; Mon, 1 Apr 2013 12:09:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Apr 2013 12:09:11 -0700 Message-ID: From: Andre Kostur To: VithalPrasad Gaitonde Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl4WXAIbVq5I7ogdX0XYEgfSpgHeNBW6dv8c8M+fNLUDTuK2ttXgEN430Rn3i8D7zE2yYDpz2aKeXscKd9at/mBtbvzm/ueFuRNy2wtr4curSxrNNBvFYlrj/lAgRdvvxgR9bewsYq39GaUpSNpvDImyXYeOg== Cc: "" Subject: Re: [dhcwg] DHCP in virtualized networks/Multi-tenant DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:09:13 -0000 On Mon, Apr 1, 2013 at 11:59 AM, VithalPrasad Gaitonde wrote: > Is there any guidance (BCP ?) on using DHCP in network virtualization > environments. Alternatively, is there interest in the working group on > arriving at a guidance if there isn't one already. It would help if you clarified what you mean by "network virtualization environments". What sort of issues do you see happening? -- Andre Kostur From volz@cisco.com Mon Apr 1 20:12:23 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A111E21E8151 for ; Mon, 1 Apr 2013 20:12:23 -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 4RX41uYx12AW for ; Mon, 1 Apr 2013 20:12:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3CC21E814D for ; Mon, 1 Apr 2013 20:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10297; q=dns/txt; s=iport; t=1364872342; x=1366081942; h=from:to:subject:date:message-id:mime-version; bh=ORmcWrDeQl9JwZ4GzKYOV0SuXlOILHxFRnEo5sDySTo=; b=kQSi5YYlcYm5VJwIFpD5uaAmY4BtY1vSS5UibkaAcpI7o0x7q+OkvXMw sY4fjsECF/ZGMb3zUjZYMn+xhHnCZpNxZCz7L1Hq9Ub8tJDecv3lRBItP qo7JhTFlc2pRoPMcjDl5CmYJGT0aWwD3XyKi4MKiUxpsn7uuJjGTFRshw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFADxMWlGtJV2d/2dsb2JhbABDgkN4twYBiDx+FnSCHwEBAQQtXgEZBAEBCx05FAkJAQQTCIgMDJ98kRWPeokShWcmEYJgYQOYCo9sgVWBKQ2CKA X-IronPort-AV: E=Sophos;i="4.87,391,1363132800"; d="scan'208,217";a="193642290" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Apr 2013 03:12:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r323CLMt016071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Apr 2013 03:12:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 1 Apr 2013 22:12:21 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: REMINDER - WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac4vT6Arq+FQkaxxTDCU1b5m0hWCyg== Date: Tue, 2 Apr 2013 03:12:20 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184CFCF6@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.44] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E184CFCF6xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] REMINDER - WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 03:12:23 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E184CFCF6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder ... there's been almost no feedback so far. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Sunday, March 24, 2013 4:26 PM To: dhcwg@ietf.org Subject: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond = by April 8, 2013 Folks, the authors of draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 feel it's ready fo= r a WGLC. There's been discussion and comment already, but more eyes on th= is work are definitely needed to advance it. At the time of this writing, there is no IPR reported against this draft. Please review the draft and indicate whether or not you feel it is ready to= be published. We have been getting very anemic responses to working group= messages recently. Your response matters, so please do respond. Tomek and I will evaluate consensus after April 8, 2013. Thanks! - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E184CFCF6xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder …= ; there’s been almost no feedback so far.

 

-&nb= sp;         Bernie

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Sunday, March 24, 2013 4:26 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - R= espond by April 8, 2013

 

Folks, the authors of draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 feel it's ready for a WGLC.&nb= sp; There's been discussion and comment already, but more eyes on this work= are definitely needed to advance it.

 

At the time of this writing, there is no IPR reporte= d against this draft.

 

Please review the draft and indicate whether or not = you feel it is ready to be published.  We have been getting very anemi= c responses to working group messages recently.   Your response m= atters, so please do respond.

 

Tomek and I will evaluate consensus after April 8, 2= 013.

 

Thanks!

 

-     &= nbsp;    Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E184CFCF6xmbrcdx04ciscoc_-- From gvithal@gmail.com Tue Apr 2 11:46:09 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0E621F8CDF for ; Tue, 2 Apr 2013 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ioOMf9FQEPG for ; Tue, 2 Apr 2013 11:46:09 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2114E21F8CE9 for ; Tue, 2 Apr 2013 11:46:09 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hz11so794458vcb.9 for ; Tue, 02 Apr 2013 11:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ibPxlw5boqgEpk7/8a+MUX2NvBRABYCiTJnp/BXkfIQ=; b=E2GLVnjPPGhTDpuyDOuUHTyvlFoVs4CZudGI+Xm6CtQRpiDMhiM164Msz4k7TS8mKT VXwqfwQf8ZB48aM54xDSGJ3JwUkxhNU0sJW2iwoucMf9BLpqmjbLyciWckSjolIIWqXH 5levlHl8Gdn13APIrd1lg7d3nsCF3xMomxYuLp0un/twbB+LfPjwGj8XLhiHKEa7C4gK RQ5QYNVRGsFPqrc1Tq8NJXPHE7N/8ZUkemx0fVgS1qahIjs4pIsaXftLE+9nOJwIhJ6f TrqBveMrmzXtRt/wjhYte1dDQ8UKztKTaaurjzhG7N4P6B3fwPxgAjD/0iPC4qmdRvMr MFhw== MIME-Version: 1.0 X-Received: by 10.58.162.163 with SMTP id yb3mr13421464veb.56.1364928368442; Tue, 02 Apr 2013 11:46:08 -0700 (PDT) Received: by 10.58.147.39 with HTTP; Tue, 2 Apr 2013 11:46:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 00:16:08 +0530 Message-ID: From: VithalPrasad Gaitonde To: Andre Kostur , "" Content-Type: multipart/alternative; boundary=047d7b677be08b874804d9652695 Subject: Re: [dhcwg] DHCP in virtualized networks/Multi-tenant DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:46:09 -0000 --047d7b677be08b874804d9652695 Content-Type: text/plain; charset=ISO-8859-1 Adding the working group. Did a reply to sender out of oversight. On Wed, Apr 3, 2013 at 12:06 AM, VithalPrasad Gaitonde wrote: > I am referring to environments where tenant VMs use their own IP space > (Bring Your Own IP) in an IaaS cloud environment with GRE or VXLAN being > used for network virtualization. The problems that I see are - > 1. How does DHCP broadcast messages in the tenant network get relayed to > multi-tenant DHCP server > 2. How does DHCP server determine which tenant IP space to lease an IP > address (and options) from > > Thanks, > Prasad > > > On Tue, Apr 2, 2013 at 12:39 AM, Andre Kostur wrote: > >> On Mon, Apr 1, 2013 at 11:59 AM, VithalPrasad Gaitonde >> wrote: >> > Is there any guidance (BCP ?) on using DHCP in network virtualization >> > environments. Alternatively, is there interest in the working group on >> > arriving at a guidance if there isn't one already. >> >> It would help if you clarified what you mean by "network >> virtualization environments". What sort of issues do you see >> happening? >> >> -- >> Andre Kostur >> > > --047d7b677be08b874804d9652695 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adding the working group. Did a reply to sender out of ove= rsight.


On= Wed, Apr 3, 2013 at 12:06 AM, VithalPrasad Gaitonde <= gvithal@gmail.com> wrote:
I am referring to environme= nts where tenant VMs use their own IP space (Bring Your Own IP) in an IaaS = cloud environment with GRE or VXLAN being used for network virtualization. = The problems that I see are -
1. How does DHCP broadcast messages in the tenant network get relayed to mu= lti-tenant DHCP server
2. How does DHCP server determine which te= nant IP space to lease an IP address (and options) from

Thanks,
Prasad


On Tue, Apr 2, 2013 at 12:39 AM, Andre Kostur <akostur@incognito.co= m> wrote:
On Mon, Apr 1, 2013 at 11:59 AM, V= ithalPrasad Gaitonde
<gvithal@gmail.co= m> wrote:
> Is there any guidance (BCP ?) on using DHCP in network virtualization<= br> > environments. Alternatively, is there interest in the working group on=
> arriving at a guidance if there isn't one already.

It would help if you clarified what you mean by "network virtualization environments". =A0What sort of issues do you see
happening?

--
Andre Kostur


--047d7b677be08b874804d9652695-- From tomasz.mrugalski@gmail.com Tue Apr 2 13:07:30 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5784D21F8DAC for ; Tue, 2 Apr 2013 13:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2rXEfwfMR83 for ; Tue, 2 Apr 2013 13:07:29 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 320A221F8D09 for ; Tue, 2 Apr 2013 13:07:29 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id n15so394393ead.14 for ; Tue, 02 Apr 2013 13:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=u3gTkylzp5AXLSebwQBT9+XG8kcILcbW676QhnM7eG0=; b=B+yvZK/PHqDgbw440Ar9QGbWVxxSRDjom2wRsaGdkvVfQ6kWBcTpuwQvl+z/zgkYzQ UTxSXcUwXs05jl+sUYME/b1dozga9FkQX05EWpW+pz/PoUeC1S17jXLwxwPI2PfGYe7r M6iwiTOEUbKXu96yTeHNuPOjiKNdaCADPF1nc8j8ty7esIlmqr1peM88yfEoKhJReQVC g6cm7iZ1aQ/1DioddLZEz6X8iC8uax98oaBq5OAVHcFKXgFvH7t9RziXb/L4+rf3on5L DyslDq/NpAmJ31dH9jvWZ6vuWB68/NaNu3+Iy245ToUPRnaB04XG4K6csk/OxF7NDpdv X6Aw== X-Received: by 10.15.35.193 with SMTP id g41mr52511307eev.45.1364933248302; Tue, 02 Apr 2013 13:07:28 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:ac0f:d984:8369:5b40? ([2001:470:6061:1:ac0f:d984:8369:5b40]) by mx.google.com with ESMTPS id f47sm4715249eep.13.2013.04.02.13.07.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 13:07:27 -0700 (PDT) Message-ID: <515B3A7C.8040507@gmail.com> Date: Tue, 02 Apr 2013 22:07:24 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09 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 Apr 2013 20:07:30 -0000 Leaf, Med, I'm writing a shepherding document for draft-yeh-dhc-dhcpv6-authorization-opt. As part of this process, I reviewed this document one more time and have a couple of questions/comments. Questions: 1. Was this document presented and reviewed in RADEXT? I'm satisfied with the depth and breadth of reviews this document received in DHC, but I'm concerned with the reviews from RADIUS perspective. I found only one post about it to RADEXT wg: http://www.ietf.org/mail-archive/web/radext/current/msg07717.html. Was this draft presented in RADEXT meeting? Was it discussed on RADEXT mailing list? If not, what is the reason? 2. There are 2 warnings reported by idnits: - lack of boilerplate RFC2119 text (there is a text in section 2, but you do not use exact wording as RFC2119 suggests, so idnits gets confused) - missing references in line 265 (some type codes are marked as [TBD], which confuse idnits as a to be defined references. Removing the brackets should solve this idnits issue). Can you please post updated version that solves this? Review comments: Title: "RADIUS Option for DHCPv6 Relay Agent on the Broadband Access Servers" While the primary usage scenario for this mechanism is NAS, this mechanism can be used in a generic case on any relay that happens to also be Radius client. I propose to remove "on the Broadband Access Servers" from the title. If you want to keep it, please add somewhere in the Introduction a text that explains that while deploying this mechanism on NAS is the primary use case, it may be useful in other deployment types as well. You may compare this with RFC4014 and its title. Section 1 introduction. Please remove "etc." from "The stateful configuration parameters include IPv6 address[RFC3315], IPv6 prefix [RFC3633], etc.". Currently there are no other stateful configuration parameters. You may add a text here about this being a generic mechanism and that NAS happen to be the obvious usage scenario. A single sentence will do the trick. Section 2: idnits (http://tools.ietf.org/tools/idnits/) reports that the RFC2119 boilerplate does not include exact expected text. Can you fix it? Section 3, figure 1 and 2: Can you rename the NAS box to NAS/DHCPv6 relay? Its double function is rather obvious from the types of received and transmitted messages, but it makes the figure a bit easier to understand. Section 4. Can you put the initial list of attributes in a separate subsection (4.1)? This will make it easier for IANA guys to understand. Make sure you reference this new 4.1 section from IANA considerations section. Section 4 says that the following attributes may be stored in the RADIUS option, but do not specify clearly how to encode them. There is a text that references section 5 of RFC2865 and inclusion of length and type fields, but this is still confusing. The current text is ambiguous if the type and length are 1 octet wide (Radius style) or 2 octets wide (DHCPv6 style). This should be clarified. It would also be helpful, if you could add a section 4.2 that provides a simple example. You may take a look at RFC6334, section 3. Section 5 enumerates several message types, DHCPv6 options and Radius attributes. Some of them are accompanied with values in parentheses and some of them are not. Please unify this - either mention values for all or for none. In section 5 you refer to RADIUS option as container option. Please call it just OPTION_RADIUS as you do in the rest of the text. Section 6 is called Server Behavior. Usually this is correct, but in this context "server" is ambiguous (DHCPv6 server or RADIUS server?). Please rename it to DHCPv6 Server Behavior. The same applies to sections 5. and 7. Section 6 has the following text "Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a relay agent, the DHCPv6 server SHOULD extract and interpret the RADIUS attributes in the OPTION_RADIUS, and use that information in selecting configuration parameters for the requesting client.". I would argue that SHOULD is too strong and MAY should be used instead. Whether the server uses or not the contents of RADIUS option is really a matter of server policy which is up to network administrator, so SHOULD is too strong here. Section 9 "IANA considerations" requires a small update. You ask IANA to define a new registry "RADIUS Attributes Permitted in the DHCPv6 RADIUS option". It is almost good, but you did not specify initial content of this new registry in the IANA consideration section. Adding a simple reference to section 4 (or a section 4.1 as suggested earlier in my mail) should do solve this issue. There's a formal question in IESG write-up that specifically asks about this and doing it now will save us a lot of hassles and delays later in the IESG review process. Why there is no reference to RFC4014 that defines exactly the same mechanism for DHCPv4? Once you'll address those comments (or respond that you chose to not change the text), please upload updated version. I'll then resume my work on shepherding this document. Make sure this new version do not have any issues reported by idnits. Tomek From leaf.yeh.sdo@gmail.com Wed Apr 3 07:03:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5814B21F8E51 for ; Wed, 3 Apr 2013 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 PGPmCYX-SHsp for ; Wed, 3 Apr 2013 07:03:43 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id E823F21F8DEF for ; Wed, 3 Apr 2013 07:03:42 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id um15so872304pbc.36 for ; Wed, 03 Apr 2013 07:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=gtNV3ouaLWfIWoBoZ2NioETijfko71T15fGbui3uSho=; b=ssuA5qDd7JrH1MrLa9QcNiM1oFMcbbRjt3HpL67Mfyp56uFmoqvRkPa0GffRGJDuK9 Z0Ar27opc5pwfno71Gjs3A6JFLKDPR7nsm6JjoGBk0Hg3FNSquod64v4AEghA4tPATb8 aPEyZRHF5uXWbw8OVXEGlTM+9p/9sbwbmrn4Wy0+S8xv2fs4RmbLIw0XXC4UReEy/DD3 e0OjHTnpk4lt8/5Wxq9JKoUKoEW7Xt5WUOWQapKdQy+c/Bt3rJuTDfJVEccsKeMNlN4h 8fS308QLAgok5Qv5cBaZLaoiOvO6HXkdmOVmHr7lkuy0zu2uXv4hcyr1UfafpDGK5ylo BGbw== X-Received: by 10.66.197.136 with SMTP id iu8mr3581123pac.0.1364997821901; Wed, 03 Apr 2013 07:03:41 -0700 (PDT) Received: from PC ([114.248.237.142]) by mx.google.com with ESMTPS id ky10sm7051162pab.23.2013.04.03.07.03.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Apr 2013 07:03:41 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" , "'dhcwg'" References: <515B3A7C.8040507@gmail.com> In-Reply-To: <515B3A7C.8040507@gmail.com> Date: Wed, 3 Apr 2013 22:03:29 +0800 Message-ID: <515c36bd.0a78420a.417b.ffffd8c1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4v3ba28YozyVagTRSzIDddHv2m7AAS0Ghw Content-Language: zh-cn Subject: Re: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09 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 Apr 2013 14:03:44 -0000 Hi Tomek, Thanks for the co-chair's thoroughly review again. :-) Tomek - 1. Was this document presented and reviewed in RADEXT? I'm satisfied with the depth and breadth of reviews this document received in DHC, but I'm concerned with the reviews from RADIUS perspective. I found only one post about it to RADEXT wg: http://www.ietf.org/mail-archive/web/radext/current/msg07717.html. Was this draft presented in RADEXT meeting? Was it discussed on RADEXT mailing list? If not, what is the reason? I am not sure the draft (OPTION_RADIUS) has been reviewed in the ML of RADEXT-WG yet, though it is always in the ML of AAA-DOCTORS (http://www.ietf.org/mail-archive/web/aaa-doctors/current/maillist.html ). I suppose RADEXT-WG still has the chance to review it in the period of IESG LC. Tomek - 2. There are 2 warnings reported by idnits: - lack of boilerplate RFC2119 text (there is a text in section 2, but you do not use exact wording as RFC2119 suggests, so idnits gets confused) Per the requirement of RFC2119, the text will be updated to be: " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119." in the ver.-10 of draft (OPTION_RADIUS). Tomek - missing references in line 265 (some type codes are marked as [TBD], which confuse idnits as a to be defined references. Removing the brackets should solve this idnits issue). Can you please post updated version that solves this? Per the RADIUS registry of IANA (http://www.iana.org/assignments/radius-types/radius-types.xml ), the table in section 4 will be updated to be Type Code Attribute Reference 26 Vendor-Specific [RFC2865] 123 Delegated-IPv6-Prefix [RFC4818] 144 DS-Lite-Tunnel-Name [RFC6519] 168 Framed-IPv6-Address [I-D.ietf-radext-ipv6-access] 169 DNS-Server-IPv6-Address [I-D.ietf-radext-ipv6-access] 171 Delegated-IPv6-Prefix-Pool [I-D.ietf-radext-ipv6-access] 172 Stateful-IPv6-Address-Pool [I-D.ietf-radext-ipv6-access] in the ver.-10. Tomek - Title: "RADIUS Option for DHCPv6 Relay Agent on the Broadband Access Servers" While the primary usage scenario for this mechanism is NAS, this mechanism can be used in a generic case on any relay that happens to also be Radius client. I propose to remove "on the Broadband Access Servers" from the title. If you want to keep it, please add somewhere in the Introduction a text that explains that while deploying this mechanism on NAS is the primary use case, it may be useful in other deployment types as well. You may compare this with RFC4014 and its title. I am fine with the new title of the draft as "RADIUS Option for DHCPv6 Relay Agent" in the ver.-10. Tomek - Section 1 introduction. Please remove "etc." from "The stateful configuration parameters include IPv6 address[RFC3315], IPv6 prefix [RFC3633], etc.". Currently there are no other stateful configuration parameters. The above text will be updated to be "The stateful configuration parameters include IPv6 address[RFC3315] and IPv6 prefix [RFC3633]." in ver.-10. Tomek - You may add a text here about this being a generic mechanism and that NAS happen to be the obvious usage scenario. A single sentence will do the trick. How about to add the following text after the 1st paragraph of section 3: " The mechanism introduced in this document is a generic mechanism, and might also be employed in other network scenarios where the DHCPv6 relay agent and the RADIUS client locate in the same device." ? Tomek - Section 2: idnits (http://tools.ietf.org/tools/idnits/) reports that the RFC2119 boilerplate does not include exact expected text. Can you fix it? See the above reply. Tomek - Section 3, figure 1 and 2: Can you rename the NAS box to NAS/DHCPv6 relay? Its double function is rather obvious from the types of received and transmitted messages, but it makes the figure a bit easier to understand. How about to denote the NAS as follows: " +-------+ | NAS | | | +-------+ RADIUS Client/DHCPv6 Relay Agent" in Fig.1 & 2? Tomek - Section 4. Can you put the initial list of attributes in a separate subsection (4.1)? This will make it easier for IANA guys to understand. Make sure you reference this new 4.1 section from IANA considerations section. I am fine with it, you will get "section 4.1 RADIUS attributes permitted in DHCPv6 RADIUS option" in ver.-10. :-) Tomek - Section 4 says that the following attributes may be stored in the RADIUS option, but do not specify clearly how to encode them. There is a text that references section 5 of RFC2865 and inclusion of length and type fields, but this is still confusing. The current text is ambiguous if the type and length are 1 octet wide (Radius style) or 2 octets wide (DHCPv6 style). This should be clarified. It would also be helpful, if you could add a section 4.2 that provides a simple example. You may take a look at RFC6334, section 3. The RADIUS attributes are included in the OPTION_RADIUS one by one, cause they are in TLV format. The note after the table of "RADIUS attributes permitted in DHCPv6 RADIUS option" is a note for the difference in TLV format defined for RADIUS attribute with that defined for DHCPv6 option. I meant the DHCPv6 option's 'Length' (option-len) does not include the length of 'Type' and 'Length' fields, but the RADIUS attribute's 'Length' does. The text could be updated to be "Note: The RADIUS attribute's 'Length' defined in section 5 of RFC2865, includes the length of 'Type' and 'Length' fields.", OK? Tomek - In section 5 you refer to RADIUS option as container option. Please call it just OPTION_RADIUS as you do in the rest of the text. I am fine with it. How about to update the text to be "...the relay agent that supports OPTION_RADIUS SHOULD include these RADIUS attributes into the OPTION_RADIUS one by one." for the above 2 questions? Tomek - Section 5 enumerates several message types, DHCPv6 options and Radius attributes. Some of them are accompanied with values in parentheses and some of them are not. Please unify this - either mention values for all or for none. The text in section 5 will be updated to be "When the value in the attributes of Delegated-IPv6-Prefix-Pool (171), Stateful-IPv6-Address-Pool (172),Delegated-IPv6-Prefix (123) or Framed-IPv6-Address (168) in the Access-Accept message replied from RADIUS server are valid, ..." in ver.-10, cause we just can get the codes from the RADIUS registry of IANA (http://www.iana.org/assignments/radius-types/radius-types.xml ) these days. Tomek - Section 6 is called Server Behavior. Usually this is correct, but in this context "server" is ambiguous (DHCPv6 server or RADIUS server?). Please rename it to DHCPv6 Server Behavior. The same applies to sections 5. and 7. I am fine with it. The titles of section 5,6 & 7 will be updated to be "DHCPv6 Relay Agent Behavior", "DHCPv6 Server Behavior" & "DHCPv6 Client Behavior" in ver.-10. Tomek - Section 6 has the following text "Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a relay agent, the DHCPv6 server SHOULD extract and interpret the RADIUS attributes in the OPTION_RADIUS, and use that information in selecting configuration parameters for the requesting client.". I would argue that SHOULD is too strong and MAY should be used instead. Whether the server uses or not the contents of RADIUS option is really a matter of server policy which is up to network administrator, so SHOULD is too strong here. How about "...the DHCPv6 server that supports OPTION_RADIUS SHOULD..." ? Tomek - Section 9 "IANA considerations" requires a small update. You ask IANA to define a new registry "RADIUS Attributes Permitted in the DHCPv6 RADIUS option". It is almost good, but you did not specify initial content of this new registry in the IANA consideration section. Adding a simple reference to section 4 (or a section 4.1 as suggested earlier in my mail) should do solve this issue. There's a formal question in IESG write-up that specifically asks about this and doing it now will save us a lot of hassles and delays later in the IESG review process. I am fine with it. The text will be updated to be: "This document requests to assign a new DHCPv6 option code for OPTION_RADIUS defined in section 4, and to create a new registry on the same assignment page, which is entitled as 'RADIUS attributes permitted in DHCPv6 RADIUS option' defined in section 4.1." in the ver.-10. Tomek - Why there is no reference to RFC4014 that defines exactly the same mechanism for DHCPv4? I guess the text associated with RFC4014 has been dropped from the ver.-04 per the comment in the ML (http://www.ietf.org/mail-archive/web/dhcwg/current/msg13350.html). Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 03, 2013 4:07 AM To: dhcwg Subject: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09 Leaf, Med, I'm writing a shepherding document for draft-yeh-dhc-dhcpv6-authorization-opt. As part of this process, I reviewed this document one more time and have a couple of questions/comments. Questions: 1. Was this document presented and reviewed in RADEXT? I'm satisfied with the depth and breadth of reviews this document received in DHC, but I'm concerned with the reviews from RADIUS perspective. I found only one post about it to RADEXT wg: http://www.ietf.org/mail-archive/web/radext/current/msg07717.html. Was this draft presented in RADEXT meeting? Was it discussed on RADEXT mailing list? If not, what is the reason? 2. There are 2 warnings reported by idnits: - lack of boilerplate RFC2119 text (there is a text in section 2, but you do not use exact wording as RFC2119 suggests, so idnits gets confused) - missing references in line 265 (some type codes are marked as [TBD], which confuse idnits as a to be defined references. Removing the brackets should solve this idnits issue). Can you please post updated version that solves this? Review comments: Title: "RADIUS Option for DHCPv6 Relay Agent on the Broadband Access Servers" While the primary usage scenario for this mechanism is NAS, this mechanism can be used in a generic case on any relay that happens to also be Radius client. I propose to remove "on the Broadband Access Servers" from the title. If you want to keep it, please add somewhere in the Introduction a text that explains that while deploying this mechanism on NAS is the primary use case, it may be useful in other deployment types as well. You may compare this with RFC4014 and its title. Section 1 introduction. Please remove "etc." from "The stateful configuration parameters include IPv6 address[RFC3315], IPv6 prefix [RFC3633], etc.". Currently there are no other stateful configuration parameters. You may add a text here about this being a generic mechanism and that NAS happen to be the obvious usage scenario. A single sentence will do the trick. Section 2: idnits (http://tools.ietf.org/tools/idnits/) reports that the RFC2119 boilerplate does not include exact expected text. Can you fix it? Section 3, figure 1 and 2: Can you rename the NAS box to NAS/DHCPv6 relay? Its double function is rather obvious from the types of received and transmitted messages, but it makes the figure a bit easier to understand. Section 4. Can you put the initial list of attributes in a separate subsection (4.1)? This will make it easier for IANA guys to understand. Make sure you reference this new 4.1 section from IANA considerations section. Section 4 says that the following attributes may be stored in the RADIUS option, but do not specify clearly how to encode them. There is a text that references section 5 of RFC2865 and inclusion of length and type fields, but this is still confusing. The current text is ambiguous if the type and length are 1 octet wide (Radius style) or 2 octets wide (DHCPv6 style). This should be clarified. It would also be helpful, if you could add a section 4.2 that provides a simple example. You may take a look at RFC6334, section 3. Section 5 enumerates several message types, DHCPv6 options and Radius attributes. Some of them are accompanied with values in parentheses and some of them are not. Please unify this - either mention values for all or for none. In section 5 you refer to RADIUS option as container option. Please call it just OPTION_RADIUS as you do in the rest of the text. Section 6 is called Server Behavior. Usually this is correct, but in this context "server" is ambiguous (DHCPv6 server or RADIUS server?). Please rename it to DHCPv6 Server Behavior. The same applies to sections 5. and 7. Section 6 has the following text "Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a relay agent, the DHCPv6 server SHOULD extract and interpret the RADIUS attributes in the OPTION_RADIUS, and use that information in selecting configuration parameters for the requesting client.". I would argue that SHOULD is too strong and MAY should be used instead. Whether the server uses or not the contents of RADIUS option is really a matter of server policy which is up to network administrator, so SHOULD is too strong here. Section 9 "IANA considerations" requires a small update. You ask IANA to define a new registry "RADIUS Attributes Permitted in the DHCPv6 RADIUS option". It is almost good, but you did not specify initial content of this new registry in the IANA consideration section. Adding a simple reference to section 4 (or a section 4.1 as suggested earlier in my mail) should do solve this issue. There's a formal question in IESG write-up that specifically asks about this and doing it now will save us a lot of hassles and delays later in the IESG review process. Why there is no reference to RFC4014 that defines exactly the same mechanism for DHCPv4? Once you'll address those comments (or respond that you chose to not change the text), please upload updated version. I'll then resume my work on shepherding this document. Make sure this new version do not have any issues reported by idnits. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Wed Apr 3 07:34:36 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42421F8A8A; Wed, 3 Apr 2013 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, 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 gSzmCvDy8Rk0; Wed, 3 Apr 2013 07:34:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EB221F8A09; Wed, 3 Apr 2013 07:34:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130403143435.15410.48486.idtracker@ietfa.amsl.com> Date: Wed, 03 Apr 2013 07:34:35 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:34:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agent Author(s) : Leaf Y. Yeh Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-radius-opt-10.txt Pages : 11 Date : 2013-04-03 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.yeh.sdo@gmail.com Wed Apr 3 07:45:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31CA21F8DBF for ; Wed, 3 Apr 2013 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 vQcV3f9SzOTF for ; Wed, 3 Apr 2013 07:45:52 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 72B7321F8DB2 for ; Wed, 3 Apr 2013 07:45:51 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so939818pad.2 for ; Wed, 03 Apr 2013 07:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=wIip3EbqH9p7t+auXVqQivnjo3i5HoIwQJsq/YuV3JQ=; b=QOdSXVHde3Pjq//3ng19nKYT5XiBxxoPnUOPQU+VVWIyZuJbx8UHhz9nf9AXr4pFh1 k/VcxEQIjJne5FRLVp4vr04aWT/JqysLTAH9G/LZOH5SR01w8hzRiRKFgdkwoDN1Uthl NWjyiIAr4Hia2DK+Z2QSaFT7grQ4C6Ar5NbQJJQhOXdonWivvCQt06CACqzhj3pypfzY RNoNU4MnOfX0wNxgQEAB7jCALOIRgASJ7VxOYGuUEOSDjuLPzpvV8L99gxFp6WDzn0C3 pe+BjVUN/JjYgkyA38h776yBEbCzOy0hxuJCCN++04bIo13JHTckev2S6eRrVdjYSujp Dy3g== X-Received: by 10.66.121.169 with SMTP id ll9mr3555255pab.178.1365000351140; Wed, 03 Apr 2013 07:45:51 -0700 (PDT) Received: from PC ([114.248.237.142]) by mx.google.com with ESMTPS id mz8sm6297188pbc.9.2013.04.03.07.45.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Apr 2013 07:45:50 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" , "'dhcwg'" References: <515B3A7C.8040507@gmail.com> In-Reply-To: Date: Wed, 3 Apr 2013 22:45:39 +0800 Message-ID: <515c409e.28d3440a.7f25.ffffc7a6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4v3ba28YozyVagTRSzIDddHv2m7AAS0GhwABMSODA= Content-Language: zh-cn Subject: Re: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09 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 Apr 2013 14:45:54 -0000 Tomek - Once you'll address those comments (or respond that you chose to not change the text), please upload updated version. I'll then resume my work on shepherding this document. Make sure this new version do not have any issues reported by idnits. The draft (OPTION_RADIUS) has been updated to be ver.-10. (http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/?include_t ext=1) The update from ver.-09 can be check here. (http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-10) The exact wording as RFC2119 suggests is from here. (http://tools.ietf.org/html/rfc2119) Some [TBD]s have been updated to be the codes of the newly defined RADIUS attributes per the registry of IANA. (http://www.iana.org/assignments/radius-types/radius-types.xml ) Best Regards, Leaf -----Original Message----- From: Leaf Yeh [mailto:leaf.yeh.sdo@gmail.com] Sent: Wednesday, April 03, 2013 10:03 PM To: 'Tomek Mrugalski'; 'dhcwg' Cc: 'mohamed.boucadair@orange.com' Subject: RE: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09 Hi Tomek, Thanks for the co-chair's thoroughly review again. :-) Tomek - 1. Was this document presented and reviewed in RADEXT? I'm satisfied with the depth and breadth of reviews this document received in DHC, but I'm concerned with the reviews from RADIUS perspective. I found only one post about it to RADEXT wg: http://www.ietf.org/mail-archive/web/radext/current/msg07717.html. Was this draft presented in RADEXT meeting? Was it discussed on RADEXT mailing list? If not, what is the reason? I am not sure the draft (OPTION_RADIUS) has been reviewed in the ML of RADEXT-WG yet, though it is always in the ML of AAA-DOCTORS (http://www.ietf.org/mail-archive/web/aaa-doctors/current/maillist.html ). I suppose RADEXT-WG still has the chance to review it in the period of IESG LC. Tomek - 2. There are 2 warnings reported by idnits: - lack of boilerplate RFC2119 text (there is a text in section 2, but you do not use exact wording as RFC2119 suggests, so idnits gets confused) Per the requirement of RFC2119, the text will be updated to be: " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119." in the ver.-10 of draft (OPTION_RADIUS). Tomek - missing references in line 265 (some type codes are marked as [TBD], which confuse idnits as a to be defined references. Removing the brackets should solve this idnits issue). Can you please post updated version that solves this? Per the RADIUS registry of IANA (http://www.iana.org/assignments/radius-types/radius-types.xml ), the table in section 4 will be updated to be Type Code Attribute Reference 26 Vendor-Specific [RFC2865] 123 Delegated-IPv6-Prefix [RFC4818] 144 DS-Lite-Tunnel-Name [RFC6519] 168 Framed-IPv6-Address [I-D.ietf-radext-ipv6-access] 169 DNS-Server-IPv6-Address [I-D.ietf-radext-ipv6-access] 171 Delegated-IPv6-Prefix-Pool [I-D.ietf-radext-ipv6-access] 172 Stateful-IPv6-Address-Pool [I-D.ietf-radext-ipv6-access] in the ver.-10. Tomek - Title: "RADIUS Option for DHCPv6 Relay Agent on the Broadband Access Servers" While the primary usage scenario for this mechanism is NAS, this mechanism can be used in a generic case on any relay that happens to also be Radius client. I propose to remove "on the Broadband Access Servers" from the title. If you want to keep it, please add somewhere in the Introduction a text that explains that while deploying this mechanism on NAS is the primary use case, it may be useful in other deployment types as well. You may compare this with RFC4014 and its title. I am fine with the new title of the draft as "RADIUS Option for DHCPv6 Relay Agent" in the ver.-10. Tomek - Section 1 introduction. Please remove "etc." from "The stateful configuration parameters include IPv6 address[RFC3315], IPv6 prefix [RFC3633], etc.". Currently there are no other stateful configuration parameters. The above text will be updated to be "The stateful configuration parameters include IPv6 address[RFC3315] and IPv6 prefix [RFC3633]." in ver.-10. Tomek - You may add a text here about this being a generic mechanism and that NAS happen to be the obvious usage scenario. A single sentence will do the trick. How about to add the following text after the 1st paragraph of section 3: " The mechanism introduced in this document is a generic mechanism, and might also be employed in other network scenarios where the DHCPv6 relay agent and the RADIUS client locate in the same device." ? Tomek - Section 2: idnits (http://tools.ietf.org/tools/idnits/) reports that the RFC2119 boilerplate does not include exact expected text. Can you fix it? See the above reply. Tomek - Section 3, figure 1 and 2: Can you rename the NAS box to NAS/DHCPv6 relay? Its double function is rather obvious from the types of received and transmitted messages, but it makes the figure a bit easier to understand. How about to denote the NAS as follows: " +-------+ | NAS | | | +-------+ RADIUS Client/DHCPv6 Relay Agent" in Fig.1 & 2? Tomek - Section 4. Can you put the initial list of attributes in a separate subsection (4.1)? This will make it easier for IANA guys to understand. Make sure you reference this new 4.1 section from IANA considerations section. I am fine with it, you will get "section 4.1 RADIUS attributes permitted in DHCPv6 RADIUS option" in ver.-10. :-) Tomek - Section 4 says that the following attributes may be stored in the RADIUS option, but do not specify clearly how to encode them. There is a text that references section 5 of RFC2865 and inclusion of length and type fields, but this is still confusing. The current text is ambiguous if the type and length are 1 octet wide (Radius style) or 2 octets wide (DHCPv6 style). This should be clarified. It would also be helpful, if you could add a section 4.2 that provides a simple example. You may take a look at RFC6334, section 3. The RADIUS attributes are included in the OPTION_RADIUS one by one, cause they are in TLV format. The note after the table of "RADIUS attributes permitted in DHCPv6 RADIUS option" is a note for the difference in TLV format defined for RADIUS attribute with that defined for DHCPv6 option. I meant the DHCPv6 option's 'Length' (option-len) does not include the length of 'Type' and 'Length' fields, but the RADIUS attribute's 'Length' does. The text could be updated to be "Note: The RADIUS attribute's 'Length' defined in section 5 of RFC2865, includes the length of 'Type' and 'Length' fields.", OK? Tomek - In section 5 you refer to RADIUS option as container option. Please call it just OPTION_RADIUS as you do in the rest of the text. I am fine with it. How about to update the text to be "...the relay agent that supports OPTION_RADIUS SHOULD include these RADIUS attributes into the OPTION_RADIUS one by one." for the above 2 questions? Tomek - Section 5 enumerates several message types, DHCPv6 options and Radius attributes. Some of them are accompanied with values in parentheses and some of them are not. Please unify this - either mention values for all or for none. The text in section 5 will be updated to be "When the value in the attributes of Delegated-IPv6-Prefix-Pool (171), Stateful-IPv6-Address-Pool (172), Delegated-IPv6-Prefix (123) or Framed-IPv6-Address (168) in the Access-Accept message replied from RADIUS server are valid, ..." in ver.-10, cause we just can get the codes from the RADIUS registry of IANA (http://www.iana.org/assignments/radius-types/radius-types.xml ) these days. Tomek - Section 6 is called Server Behavior. Usually this is correct, but in this context "server" is ambiguous (DHCPv6 server or RADIUS server?). Please rename it to DHCPv6 Server Behavior. The same applies to sections 5. and 7. I am fine with it. The titles of section 5,6 & 7 will be updated to be "DHCPv6 Relay Agent Behavior", "DHCPv6 Server Behavior" & "DHCPv6 Client Behavior" in ver.-10. Tomek - Section 6 has the following text "Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a relay agent, the DHCPv6 server SHOULD extract and interpret the RADIUS attributes in the OPTION_RADIUS, and use that information in selecting configuration parameters for the requesting client.". I would argue that SHOULD is too strong and MAY should be used instead. Whether the server uses or not the contents of RADIUS option is really a matter of server policy which is up to network administrator, so SHOULD is too strong here. How about "...the DHCPv6 server that supports OPTION_RADIUS SHOULD..." ? Tomek - Section 9 "IANA considerations" requires a small update. You ask IANA to define a new registry "RADIUS Attributes Permitted in the DHCPv6 RADIUS option". It is almost good, but you did not specify initial content of this new registry in the IANA consideration section. Adding a simple reference to section 4 (or a section 4.1 as suggested earlier in my mail) should do solve this issue. There's a formal question in IESG write-up that specifically asks about this and doing it now will save us a lot of hassles and delays later in the IESG review process. I am fine with it. The text will be updated to be: "This document requests to assign a new DHCPv6 option code for OPTION_RADIUS defined in section 4, and to create a new registry on the same assignment page, which is entitled as 'RADIUS attributes permitted in DHCPv6 RADIUS option' defined in section 4.1." in the ver.-10. Tomek - Why there is no reference to RFC4014 that defines exactly the same mechanism for DHCPv4? I guess the text associated with RFC4014 has been dropped from the ver.-04 per the comment in the ML (http://www.ietf.org/mail-archive/web/dhcwg/current/msg13350.html). Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 03, 2013 4:07 AM To: dhcwg Subject: [dhcwg] Review/shepherding for draft-ietf-dhc-dhcpv6-radius-opt-09 Leaf, Med, I'm writing a shepherding document for draft-yeh-dhc-dhcpv6-authorization-opt. As part of this process, I reviewed this document one more time and have a couple of questions/comments. Questions: 1. Was this document presented and reviewed in RADEXT? I'm satisfied with the depth and breadth of reviews this document received in DHC, but I'm concerned with the reviews from RADIUS perspective. I found only one post about it to RADEXT wg: http://www.ietf.org/mail-archive/web/radext/current/msg07717.html. Was this draft presented in RADEXT meeting? Was it discussed on RADEXT mailing list? If not, what is the reason? 2. There are 2 warnings reported by idnits: - lack of boilerplate RFC2119 text (there is a text in section 2, but you do not use exact wording as RFC2119 suggests, so idnits gets confused) - missing references in line 265 (some type codes are marked as [TBD], which confuse idnits as a to be defined references. Removing the brackets should solve this idnits issue). Can you please post updated version that solves this? Review comments: Title: "RADIUS Option for DHCPv6 Relay Agent on the Broadband Access Servers" While the primary usage scenario for this mechanism is NAS, this mechanism can be used in a generic case on any relay that happens to also be Radius client. I propose to remove "on the Broadband Access Servers" from the title. If you want to keep it, please add somewhere in the Introduction a text that explains that while deploying this mechanism on NAS is the primary use case, it may be useful in other deployment types as well. You may compare this with RFC4014 and its title. Section 1 introduction. Please remove "etc." from "The stateful configuration parameters include IPv6 address[RFC3315], IPv6 prefix [RFC3633], etc.". Currently there are no other stateful configuration parameters. You may add a text here about this being a generic mechanism and that NAS happen to be the obvious usage scenario. A single sentence will do the trick. Section 2: idnits (http://tools.ietf.org/tools/idnits/) reports that the RFC2119 boilerplate does not include exact expected text. Can you fix it? Section 3, figure 1 and 2: Can you rename the NAS box to NAS/DHCPv6 relay? Its double function is rather obvious from the types of received and transmitted messages, but it makes the figure a bit easier to understand. Section 4. Can you put the initial list of attributes in a separate subsection (4.1)? This will make it easier for IANA guys to understand. Make sure you reference this new 4.1 section from IANA considerations section. Section 4 says that the following attributes may be stored in the RADIUS option, but do not specify clearly how to encode them. There is a text that references section 5 of RFC2865 and inclusion of length and type fields, but this is still confusing. The current text is ambiguous if the type and length are 1 octet wide (Radius style) or 2 octets wide (DHCPv6 style). This should be clarified. It would also be helpful, if you could add a section 4.2 that provides a simple example. You may take a look at RFC6334, section 3. Section 5 enumerates several message types, DHCPv6 options and Radius attributes. Some of them are accompanied with values in parentheses and some of them are not. Please unify this - either mention values for all or for none. In section 5 you refer to RADIUS option as container option. Please call it just OPTION_RADIUS as you do in the rest of the text. Section 6 is called Server Behavior. Usually this is correct, but in this context "server" is ambiguous (DHCPv6 server or RADIUS server?). Please rename it to DHCPv6 Server Behavior. The same applies to sections 5. and 7. Section 6 has the following text "Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a relay agent, the DHCPv6 server SHOULD extract and interpret the RADIUS attributes in the OPTION_RADIUS, and use that information in selecting configuration parameters for the requesting client.". I would argue that SHOULD is too strong and MAY should be used instead. Whether the server uses or not the contents of RADIUS option is really a matter of server policy which is up to network administrator, so SHOULD is too strong here. Section 9 "IANA considerations" requires a small update. You ask IANA to define a new registry "RADIUS Attributes Permitted in the DHCPv6 RADIUS option". It is almost good, but you did not specify initial content of this new registry in the IANA consideration section. Adding a simple reference to section 4 (or a section 4.1 as suggested earlier in my mail) should do solve this issue. There's a formal question in IESG write-up that specifically asks about this and doing it now will save us a lot of hassles and delays later in the IESG review process. Why there is no reference to RFC4014 that defines exactly the same mechanism for DHCPv4? Once you'll address those comments (or respond that you chose to not change the text), please upload updated version. I'll then resume my work on shepherding this document. Make sure this new version do not have any issues reported by idnits. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From msiodelski@gmail.com Wed Apr 3 10:20:56 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379AD21F8CEC for ; Wed, 3 Apr 2013 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.936 X-Spam-Level: X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 Zbtp9euObM7Y for ; Wed, 3 Apr 2013 10:20:55 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CB09F21F8CB5 for ; Wed, 3 Apr 2013 10:20:54 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so764203eaj.21 for ; Wed, 03 Apr 2013 10:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:date:content-type:x-mailer :mime-version:content-transfer-encoding; bh=7Eo5Hho/TJeJvWEXKMChHBzUVBG18oZB0WqOziUalDQ=; b=JS04mq7LMFal/4JYfP4K6XOWjwrulTccLj8hkcvL8CXWngO+Ukwkm+2ba05m69+PmE UUuoLti7/aCALMGnk68AHtF75s1iuApkWye9kY8Y4nZeClIAE66CM/KsJVnsEeGX6ZUR B6sjPwZOYK/Hj/pRUYkbqV255AI9FJ/K1Ef1hEAGOUgxHcKQi0k0EvIwfEsO0NLyPDEt W9hGTFhZhe575yglBK5P/ylp3D4PEUU+zU+OVig0lKQzQv7NDtlz0sYnW49MbxcXhdQl CccwVpkUL+vOQ0Tq54g2VSE/9RLxjvXYTql+j1YZHa6MJ/kbBuHjh5HCC+9op3tUQ40w bncA== X-Received: by 10.15.22.197 with SMTP id f45mr4796746eeu.46.1365009644658; Wed, 03 Apr 2013 10:20:44 -0700 (PDT) Received: from [192.168.0.193] (89-75-115-194.dynamic.chello.pl. [89.75.115.194]) by mx.google.com with ESMTPS id s3sm8594923eem.4.2013.04.03.10.20.42 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 03 Apr 2013 10:20:43 -0700 (PDT) Message-ID: <1365009642.19971.22.camel@marcin-lenovo> From: Marcin Siodelski To: "dhcwg@ietf.org" Date: Wed, 03 Apr 2013 19:20:42 +0200 Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.6.4 (3.6.4-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Requesting adoption of draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:20:56 -0000 In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am asking for adoption of this document by DHC WG. The latest version (-01) is available here: http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6-01.txt http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 This document describes a mechanism whereby IPv4 client obtains its configuration from the DHCPv4 server separated from the client by IPv6- only network having DHCPv6 service. This mechanism is frequently referred as "DHCPv4-over-DHCPv6". The DHCPv4 client's request is carried in the newly defined DHCPv6 messages/option to/from the server and can be sent either through a relay or directly. Cheers, Marcin From tomasz.mrugalski@gmail.com Wed Apr 3 10:26:08 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0521F8C85 for ; Wed, 3 Apr 2013 10:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc0srtN1Ui2E for ; Wed, 3 Apr 2013 10:26:07 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 58FB221F8C04 for ; Wed, 3 Apr 2013 10:26:07 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id m14so735816eaj.19 for ; Wed, 03 Apr 2013 10:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:x-forwarded-message-id :content-type:content-transfer-encoding; bh=NdATTLZZae/C7Cfvvpxl8NQDaj3yRXNLrEaGma2BOzs=; b=KmaXGgIU0kOehoapms+DxI5dzH5/4ZZMv2gr/egz5FnqP5ngZqpV/4X7xSyRDGJ13A LVnwVIUZlJRlQGRNwlUu8jO7pnzHYOEmnX4/YRSc5vxJhbAfr7u4gjMKoqQSXGo0Op6f Z4qy4IfzWJa4JyJywQUUnld90b9MrOZYNrsASKjdB5iyqu/Ga/IhugvYijNIBO0QeuLK xuRi07pOFfovam+8hEMtlKSwMPX2FLAg4sr92DZr1q8iqi7Nd5xRCwWEolQ6r5gqVsQP jajfnXzTFzsZDlo11o8FmnGHiFvvl7dS5E3spoYgOqujNiHSocT/RuYvN+vcwIUPGA7M uwgQ== X-Received: by 10.15.22.76 with SMTP id e52mr5120883eeu.7.1365009964972; Wed, 03 Apr 2013 10:26:04 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:8139:7c4d:3bf3:3ecf? ([2001:470:6061:1:8139:7c4d:3bf3:3ecf]) by mx.google.com with ESMTPS id q42sm8555727eem.14.2013.04.03.10.26.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 10:26:03 -0700 (PDT) Message-ID: <515C6627.5060401@gmail.com> Date: Wed, 03 Apr 2013 19:25:59 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg References: <31BA50D5-3451-49B7-8139-8244A3E90F7A@gmail.com> In-Reply-To: <31BA50D5-3451-49B7-8139-8244A3E90F7A@gmail.com> X-TagToolbar-Keys: D20130403192559671 X-Forwarded-Message-Id: <31BA50D5-3451-49B7-8139-8244A3E90F7A@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:26:08 -0000 Hi all, This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during last IETF meeting. We were somewhat surprised to note that RFC3315 does not clarify how the relays should handle message types that they do not recognize. This draft clarifies that unknown messages should be relayed as usual. Authors requested adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-04-17. Regards, Bernie & Tomek From tomasz.mrugalski@gmail.com Wed Apr 3 10:41:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8A21F8D79 for ; Wed, 3 Apr 2013 10:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 URJ6dz8hVIDG for ; Wed, 3 Apr 2013 10:40:58 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 512E921F8D35 for ; Wed, 3 Apr 2013 10:40:58 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id c1so788932eek.0 for ; Wed, 03 Apr 2013 10:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=ZdqMaEui6a7RJ/IHVXJnEbHlsnOf9n0aeoi3UbGS/0c=; b=Ty1LC7B/L6Y3HpV8WMl+7TFyEXZJyU8w1q9XrwgJ68h4IbfIXrr14m0+GxCQFfwdi9 E02od6fGitdSIC7TgpUfSnJ8kX7JEaBuNCFC23c5GKF2/f4Tizm/+FWeWaygrnpwoZG7 z5SFzyssOBnKfnxBB3SdQZMCPUzXYPqj60xJCQ4m3WiKScQt6Wkj7GKVn2OKeRe1isF+ Q76zdW4szhc5W8YY+uTFFIexy8668MGUOrFLqyLtp3ZVWB/vFab9HdGf0A4ChLS5NdlA Y7hzeo+F7hQFvqyx5Rq3T14AT2+CKnYj061i9UfB3Zb1kWbPOIPyOAasGjblWuzL6956 Oykw== X-Received: by 10.15.34.198 with SMTP id e46mr5072611eev.27.1365010857433; Wed, 03 Apr 2013 10:40:57 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:8139:7c4d:3bf3:3ecf? ([2001:470:6061:1:8139:7c4d:3bf3:3ecf]) by mx.google.com with ESMTPS id 46sm8654424eea.3.2013.04.03.10.40.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 10:40:56 -0700 (PDT) Message-ID: <515C69A4.7000903@gmail.com> Date: Wed, 03 Apr 2013 19:40:52 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg@ietf.org References: <1365009642.19971.22.camel@marcin-lenovo> In-Reply-To: <1365009642.19971.22.camel@marcin-lenovo> X-TagToolbar-Keys: D20130403194052665 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:41:00 -0000 Hi all, This draft is a result of the discussion we had during last meeting in Orlando. We have very productive discussion about IPv4 hosts configuration in IPv6-only network. After we reached what looked like a consensus in the meeting room, couple folks volunteered to write down the draft that summarizes that perceived consensus. This draft is a product of this effort. As requested by authors, we are announcing adotion call on draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-04-17. Regards, Bernie & Tomek On 03.04.2013 19:20, Marcin Siodelski wrote: > In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am asking > for adoption of this document by DHC WG. > > The latest version (-01) is available here: > > http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6-01.txt > http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 > > This document describes a mechanism whereby IPv4 client obtains its > configuration from the DHCPv4 server separated from the client by IPv6- > only network having DHCPv6 service. This mechanism is frequently > referred as "DHCPv4-over-DHCPv6". > > The DHCPv4 client's request is carried in the newly defined DHCPv6 > messages/option to/from the server and can be sent either through a > relay or directly. > > Cheers, > Marcin > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From volz@cisco.com Wed Apr 3 11:04:29 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CEC21F8CE9 for ; Wed, 3 Apr 2013 11:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh1kchjgYScE for ; Wed, 3 Apr 2013 11:04:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6B821F8AAA for ; Wed, 3 Apr 2013 11:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3761; q=dns/txt; s=iport; t=1365012269; x=1366221869; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=uFV+uaH/V3eJwmVq+ZjVKnbifHC1zpPIUy42GhnmEVU=; b=YafTiuLcrk3cf2eqYTPCrDyRcRAiO2hVYW9XnQhcxr5Xw53vu00Ik4ah r2xTumZxE2XCpw0EnlLW/aWQ8oaATDx26ENWhMcuux52PIMfiN3TjS0z9 Isz2ouLe35FmTFNTJAuJ9910/PJZ5nj2ThgfVXvA66ajbw4BX7Db461UK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAN1uXFGtJXHB/2dsb2JhbABDgwc2wEiBDRZ0gh8BAQEEAQEBNzQLDAYBCA4DBAEBCxQJLgsUCQkBBAENBQiIDAzAUgSNZ4EBJgsNgllhA6d2gwuBczU X-IronPort-AV: E=Sophos;i="4.87,402,1363132800"; d="scan'208";a="194646823" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 03 Apr 2013 18:04:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r33I4Sd6015189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Apr 2013 18:04:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 13:04:28 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski , dhcwg Thread-Topic: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 Thread-Index: Ac4wkreb7nin94ZOTwuRlnHXXODFFA== Date: Wed, 3 Apr 2013 18:04:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:04:30 -0000 While I think it is appropriate for the WG to adopt this document, I do hav= e comments on the draft itself. The draft really should focus on the relay agent issue (what should a relay= agent do with unknown message types). I would leave the client and server = issues out of it as these are already pretty clear and I don't think there = is any value in clarifying it. Sure, if some client or server has an if the= n else list or case statement where the last "else" or the "default" case w= as a particular message, they might mis-process that message but that is a = client or server implementation issue and not an interoperability issue. For that reason, I also think the document should be retitled to be somethi= ng like "Relay Agent Handling of Unknown DHCPv6 Message Types"? This document (I believe) intends to update RFC 3315, but does not indicate= that in the header. This might be something to debate, but I would think i= t may want to make some explicit changes to RFC 3315. For example, RFC 3315= section 20.1 states: When a relay agent receives a valid message to be relayed, it constructs a new Relay-forward message. =20 So what was meant by 'valid' message? Here, I suspect you want to clarify t= his and perhaps state everything but a Relay-Reply (at least at the present= time, future documents might change this if there are messages intended fo= r the Relay -- such as the new message proposed by draft-scskf-dhc-dhcpv4-o= ver-dhcpv6). That in itself may create a slightly odd situation. I also wonder whether security considerations may allow a knob on the relay= to specify whether it MAY 'restrict' the packets it forwards (mini 'firewa= ll'). Some other nits: - Section 2, "...in RFC 3315 about [the case that] what a relay". "The case= that" can be removed. - Section 3, "leverage the information" ... what information?=20 - Section 5, "attacker can interference ... inject fake" ... attacker can i= nterfere ... by injecting? Note also that the client and server attacks for= invalid message type code packets already exists for "on-link" attacks too= . - Section 5, "yet no known vulnerabilities exist". I'm not sure it is a goo= d idea to claim this; perhaps best to just drop those words. - The document makes use of 2119 keywords yet does not indicate so. - All RFC 3315 usages should likely be to the reference. You may also want to discuss with Ted Lemon as to whether he should be an a= uthor as it may slightly complicate getting this document through the full = IETF process. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Wednesday, April 03, 2013 1:26 PM To: dhcwg Subject: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315upda= te-00 Hi all, This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during la= st IETF meeting. We were somewhat surprised to note that RFC3315 does not c= larify how the relays should handle message types that they do not recogniz= e. This draft clarifies that unknown messages should be relayed as usual. Authors requested adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being initiate= d to confirm whether there is WG consensus to adopt this work as DHC WG dra= ft. Please state whether or not you're in favor of the adoption by replying= to this mail. If you are not in favor, please also state your objections in your response= . This adoption call will complete on 2013-04-17. Regards, Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Apr 3 14:12:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4180C21F8F56 for ; Wed, 3 Apr 2013 14:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsmscHkYF8CQ for ; Wed, 3 Apr 2013 14:12:24 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 9201721F8F29 for ; Wed, 3 Apr 2013 14:12:24 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUVybOI/TUPjdCu90+jdTnrEeYCWzeCNq@postini.com; Wed, 03 Apr 2013 14:12:24 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 12BC61B8B9D for ; Wed, 3 Apr 2013 14:12:24 -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 08FCA19005C; Wed, 3 Apr 2013 14:12:24 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 14:12:24 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 Thread-Index: Ac4wkreb7nin94ZOTwuRlnHXXODFFAAV+PqA Date: Wed, 3 Apr 2013 21:12:23 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775130268@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:12:25 -0000 On Apr 3, 2013, at 2:04 PM, "Bernie Volz (volz)" wrote: > The draft really should focus on the relay agent issue (what should a rel= ay agent do with unknown message types). I would leave the client and serve= r issues out of it as these are already pretty clear and I don't think ther= e is any value in clarifying it. Sure, if some client or server has an if t= hen else list or case statement where the last "else" or the "default" case= was a particular message, they might mis-process that message but that is = a client or server implementation issue and not an interoperability issue. I don't really agree with this. I do agree with your analysis of how serv= ers and clients are likely implemented; every eval loop I've seen looks pre= tty much like what you described. However, RFC3315 does not explicitly sa= y that servers or clients should drop messages that they don't recognize, a= nd while as you say, this probably does little harm, it's certainly an omis= sion that ought to be corrected, and this seems like a convenient document = to use to correct it. > For that reason, I also think the document should be retitled to be somet= hing like "Relay Agent Handling of Unknown DHCPv6 Message Types"? And hence I disagree with this proposed change. :) > This document (I believe) intends to update RFC 3315, but does not indica= te that in the header. Good catch. > This might be something to debate, but I would think it may want to make = some explicit changes to RFC 3315. For example, RFC 3315 section 20.1 state= s: >=20 > When a relay agent receives a > valid message to be relayed, it constructs a new Relay-forward > message. =20 >=20 > So what was meant by 'valid' message? Here, I suspect you want to clarify= this and perhaps state everything but a Relay-Reply (at least at the prese= nt time, future documents might change this if there are messages intended = for the Relay -- such as the new message proposed by draft-scskf-dhc-dhcpv4= -over-dhcpv6). That in itself may create a slightly odd situation. This is a really good point. > I also wonder whether security considerations may allow a knob on the rel= ay to specify whether it MAY 'restrict' the packets it forwards (mini 'fire= wall'). An additional paragraph in Security Considerations that says this might hel= p: Nothing in this update should be construed to mean that relay agents may no= t be administratively configurable to drop messages on the basis of the mes= sage type, for security reasons (e.g., in a firewall). The sole purpose o= f requiring relay agents to relay unknown messages is to ensure that when l= egitimate new messages are defined in the protocol, relay agents, even if t= hey were manufactured prior to the definition of these new messages, will, = by default, succeed in relaying such messages. > You may also want to discuss with Ted Lemon as to whether he should be an= author as it may slightly complicate getting this document through the ful= l IETF process. Actually in this case I really am a co-author=97Qi and Yong kindly agreed t= o help me to write the document, but as you may recall I was the one who or= iginally proposed writing it. It's a pretty simple document, so I think i= t's okay if Brian gets stuck being the responsible AD for it. From volz@cisco.com Wed Apr 3 14:45:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD49721F901B for ; Wed, 3 Apr 2013 14:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VPLQKflMtp0 for ; Wed, 3 Apr 2013 14:45:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F117021F900D for ; Wed, 3 Apr 2013 14:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4173; q=dns/txt; s=iport; t=1365025548; x=1366235148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e6H3xWC7bnejR5CXhHLVDWCnG4PKpPPnT0hNXzGqIbM=; b=PnDTcxaO4oFb1aNyCD4Y5gFu30/rlqdqKfp4NtJDL8Wmu8bdFhi5Bfgp lxwt8lFhcRyO+YKVyx/1EtKL+Z9BmOPWuynCT7KkxBPnQaXhJaYmapSjW 8F7KdMQ/U++haBa6Ger35Ik3f8h8bwHzUJnySprwrgXJ1oIHTPYiY4s2S g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPOhXFGtJV2b/2dsb2JhbABDgwfBDoENFnSCHwEBAQMBOj8FBwQCAQgRBAEBAQoUCQcyFAkIAQEEDgUIiAYGwG2OaCYLBwaCWWEDp3aDC4Io X-IronPort-AV: E=Sophos;i="4.87,403,1363132800"; d="scan'208";a="194824525" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2013 21:45:47 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r33LjlXh021413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Apr 2013 21:45:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 16:45:47 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 Thread-Index: Ac4wkreb7nin94ZOTwuRlnHXXODFFAAV+PqAAA2ybgA= Date: Wed, 3 Apr 2013 21:45:46 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184D3200@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630775130268@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775130268@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.32.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:45:49 -0000 On extending beyond relays, OK. On authorship, yes I do recall you had been the one to suggest this draft -= just figured worth a comment to confirm. > The sole purpose of requiring relay agents to relay unknown messages is t= o ensure that when legitimate new messages are defined in the protocol, rel= ay agents, even if they were manufactured prior to the definition of these = new messages, will, by default, succeed in relaying such messages. I think this would be useful to mention in the draft. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, April 03, 2013 5:12 PM To: Bernie Volz (volz) Cc: Tomek Mrugalski; dhcwg Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315= update-00 On Apr 3, 2013, at 2:04 PM, "Bernie Volz (volz)" wrote: > The draft really should focus on the relay agent issue (what should a rel= ay agent do with unknown message types). I would leave the client and serve= r issues out of it as these are already pretty clear and I don't think ther= e is any value in clarifying it. Sure, if some client or server has an if t= hen else list or case statement where the last "else" or the "default" case= was a particular message, they might mis-process that message but that is = a client or server implementation issue and not an interoperability issue. I don't really agree with this. I do agree with your analysis of how serv= ers and clients are likely implemented; every eval loop I've seen looks pre= tty much like what you described. However, RFC3315 does not explicitly sa= y that servers or clients should drop messages that they don't recognize, a= nd while as you say, this probably does little harm, it's certainly an omis= sion that ought to be corrected, and this seems like a convenient document = to use to correct it. > For that reason, I also think the document should be retitled to be somet= hing like "Relay Agent Handling of Unknown DHCPv6 Message Types"? And hence I disagree with this proposed change. :) > This document (I believe) intends to update RFC 3315, but does not indica= te that in the header. Good catch. > This might be something to debate, but I would think it may want to make = some explicit changes to RFC 3315. For example, RFC 3315 section 20.1 state= s: >=20 > When a relay agent receives a > valid message to be relayed, it constructs a new Relay-forward > message. =20 >=20 > So what was meant by 'valid' message? Here, I suspect you want to clarify= this and perhaps state everything but a Relay-Reply (at least at the prese= nt time, future documents might change this if there are messages intended = for the Relay -- such as the new message proposed by draft-scskf-dhc-dhcpv4= -over-dhcpv6). That in itself may create a slightly odd situation. This is a really good point. > I also wonder whether security considerations may allow a knob on the rel= ay to specify whether it MAY 'restrict' the packets it forwards (mini 'fire= wall'). An additional paragraph in Security Considerations that says this might hel= p: Nothing in this update should be construed to mean that relay agents may no= t be administratively configurable to drop messages on the basis of the mes= sage type, for security reasons (e.g., in a firewall). The sole purpose o= f requiring relay agents to relay unknown messages is to ensure that when l= egitimate new messages are defined in the protocol, relay agents, even if t= hey were manufactured prior to the definition of these new messages, will, = by default, succeed in relaying such messages. > You may also want to discuss with Ted Lemon as to whether he should be an= author as it may slightly complicate getting this document through the ful= l IETF process. Actually in this case I really am a co-author-Qi and Yong kindly agreed to = help me to write the document, but as you may recall I was the one who orig= inally proposed writing it. It's a pretty simple document, so I think it'= s okay if Brian gets stuck being the responsible AD for it. From simon.perreault@viagenie.ca Thu Apr 4 03:42:53 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCF721F9607 for ; Thu, 4 Apr 2013 03:42:53 -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 5cFMnDma4iNz for ; Thu, 4 Apr 2013 03:42:52 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98D21F866E for ; Thu, 4 Apr 2013 03:42:52 -0700 (PDT) Received: from porto.nomis80.org (85-169-43-76.rev.numericable.fr [85.169.43.76]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E4B71414F9 for ; Thu, 4 Apr 2013 06:42:51 -0400 (EDT) Message-ID: <515D592B.4040609@viagenie.ca> Date: Thu, 04 Apr 2013 12:42:51 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg@ietf.org References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> In-Reply-To: <515C69A4.7000903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 10:42:53 -0000 Le 2013-04-03 19:40, Tomek Mrugalski a écrit : > As requested by authors, we are announcing adotion call on > draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to > confirm whether there is WG consensus to adopt this work as DHC WG > draft. Please state whether or not you're in favor of the adoption by > replying to this mail. If you are not in favor, please also state your > objections in your response. This adoption call will complete on 2013-04-17. This looks very good. I would favour adoption, but I would really like to see some discussion before. Some feedback: - In section "6. Client Behavior", it's not clear on which IPv6 interface the request for IPv4 parameters is to be sent. That knowledge would depend on the protocol that uses DHCPv4-over-IPv6. For example, if you are provisioning an IPv4-over-IPv6 tunnel interface, you would send the BOOTREQUEST6 message on the tunnel's underlying IPv6 interface. Suggestion: This document should say that future documents that define uses of DHCPv4-over-IPv6 MUST specify which IPv6 interface is to be used by the client. - In section "8. Server Behavior", it is said that the request is "passed to the DHCPv4 server engine". Is this an implementation detail (in which case it could be removed), or does it actually mean that the IPv4 message could be passed over the network to an unmodified DHCPv4 server (in which case it could be more explicit)? - Section "9. Security Considerations" says: "DHCPv6 is made a 'transport protocol' for DHCPv4 messages over an IPv6 network". This is not true unless you can use this with a pure DHCPv4 client on one side and a pure DHCPv4 server on the other. It doesn't seem to be the case according to the rest of the draft and figure 1 in particular. So, is it or is it not a transport protocol for DHCPv4? Nit: - Section 8: "This message is passed to the DHCPv4 server engine, which generates a response *to the* as specified in [RFC2131]." (remove "to the") Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From volz@cisco.com Thu Apr 4 04:34:22 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F3A21F9648 for ; Thu, 4 Apr 2013 04:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlCAcPy7qjUj for ; Thu, 4 Apr 2013 04:34:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 128C821F9607 for ; Thu, 4 Apr 2013 04:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2982; q=dns/txt; s=iport; t=1365075262; x=1366284862; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fLDOpY0pK37NzOFEDzin4NMoObHTLIrCSNeqW6avwsg=; b=HEWCxzCtoAgcZ0dt5HB20HjtiC6PKaFkL3izZtX9U0tha7rmHwwHwfqz 4RQ2da4tVV4slDgX3dTHO0XgFTozL/XiDSw3lo8r5ZY2OmZF9TgYkSERa amkMOAnLfORE7hwEfPyHGFJHZb4681hU42VpVXSSAZvSlMLph6NCKIHoL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABlkXVGtJXG//2dsb2JhbABDgwY2wQaBABZ0gh8BAQEDAQEBASRHCwULAgEIRicLJQIEDgWIDgYMwDyNZ38zB4JfYQOIQo4pgR+PbIMLgXM X-IronPort-AV: E=Sophos;i="4.87,408,1363132800"; d="scan'208";a="194907932" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 04 Apr 2013 11:34:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r34BYKPJ013954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Apr 2013 11:34:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 06:34:20 -0500 From: "Bernie Volz (volz)" To: Simon Perreault Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMSEvy9gPTdkskESP6ozPf3q78pjF7m/K Date: Thu, 4 Apr 2013 11:34:19 +0000 Message-ID: References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com>,<515D592B.4040609@viagenie.ca> In-Reply-To: <515D592B.4040609@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 11:34:23 -0000 > - In section "8. Server Behavior", it is said that the request is "passed= to the DHCPv4 server=20 This is possible but would likely require relaying the packet and that mean= s adding (and later removing) the option 82 information. Things like subnet= selection might be critical to indicate to the server where the client is = located.=20 I also support adopting this work. - Bernie On Apr 4, 2013, at 6:43 AM, "Simon Perreault" = wrote: > Le 2013-04-03 19:40, Tomek Mrugalski a =E9crit : >> As requested by authors, we are announcing adotion call on >> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to >> confirm whether there is WG consensus to adopt this work as DHC WG >> draft. Please state whether or not you're in favor of the adoption by >> replying to this mail. If you are not in favor, please also state your >> objections in your response. This adoption call will complete on 2013-04= -17. >=20 > This looks very good. I would favour adoption, but I would really like to= see some discussion before. >=20 > Some feedback: >=20 > - In section "6. Client Behavior", it's not clear on which IPv6 interface= the request for IPv4 parameters is to be sent. That knowledge would depend= on the protocol that uses DHCPv4-over-IPv6. For example, if you are provis= ioning an IPv4-over-IPv6 tunnel interface, you would send the BOOTREQUEST6 = message on the tunnel's underlying IPv6 interface. > Suggestion: This document should say that future documents that define us= es of DHCPv4-over-IPv6 MUST specify which IPv6 interface is to be used by t= he client. >=20 > - In section "8. Server Behavior", it is said that the request is "passed= to the DHCPv4 server engine". Is this an implementation detail (in which c= ase it could be removed), or does it actually mean that the IPv4 message co= uld be passed over the network to an unmodified DHCPv4 server (in which cas= e it could be more explicit)? >=20 > - Section "9. Security Considerations" says: "DHCPv6 is made a 'transport= protocol' for DHCPv4 messages over an IPv6 network". This is not true unle= ss you can use this with a pure DHCPv4 client on one side and a pure DHCPv4= server on the other. It doesn't seem to be the case according to the rest = of the draft and figure 1 in particular. So, is it or is it not a transport= protocol for DHCPv4? >=20 >=20 > Nit: >=20 > - Section 8: "This message is passed to the DHCPv4 server engine, which g= enerates a response *to the* as specified in [RFC2131]." > (remove "to the") >=20 >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Thu Apr 4 08:06:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D966A21F8556 for ; Thu, 4 Apr 2013 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTIW4HbLa3Wc for ; Thu, 4 Apr 2013 08:06:44 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A021F84DF for ; Thu, 4 Apr 2013 08:06:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUV2XA6Lkt1Pu+LhxFw9150xPBUBqzuqm@postini.com; Thu, 04 Apr 2013 08:06:44 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 C7AF610805B for ; Thu, 4 Apr 2013 08:06:43 -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 BDCB519005D; Thu, 4 Apr 2013 08:06:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 08:06:43 -0700 From: Ted Lemon To: Simon Perreault Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjGVoOAgABJuAA= Date: Thu, 4 Apr 2013 15:06:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751316C4@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <515D592B.4040609@viagenie.ca> In-Reply-To: <515D592B.4040609@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <12E8BA1902E50441BCE282C64475B901@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:06:45 -0000 On Apr 4, 2013, at 6:42 AM, Simon Perreault w= rote: > This looks very good. I would favour adoption, but I would really like to= see some discussion before. I see people say this a lot. If the working group is going to work on a d= ocument, it has to adopt it. Any discussion prior to that should be about= whether the problem ought to be worked on, and whether the document is a g= ood place to start. And that's precisely the discussion that a call for a= doption is supposed to trigger. I find it quite weird when working groups= get a document all the way to the finished state before adopting it, so es= sentially there is nothing that needs to happen between adoption and last c= all. That just doesn't make sense. Anyway, thanks for your comments=97I think they're insightful, and need to = be addressed in the document. From leaf.yeh.sdo@gmail.com Thu Apr 4 09:54:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1921F8BC0; Thu, 4 Apr 2013 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=2.546, 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 1UwTZTyZzuSg; Thu, 4 Apr 2013 09:54:43 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1D721F8BBC; Thu, 4 Apr 2013 09:54:43 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so1316273pde.4 for ; Thu, 04 Apr 2013 09:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=7jLnhIoskYEOvLFrvPJ5NsMjgeTgVKi3x5UPcppSROM=; b=0/PqdNEfXum7iGlZ/oMjFnfXWRtGCEF/aYOkxyYQnHTEZQWjDZFS29eTWpurpAEg+l wEdN7wBMo+6xFl1QCxPw2BhZUlxB5JVsfQ9wQ5ZkHtL+UC2wJpE/AHGQX0V/KcMcqAPL yJvgfnFH36VjBNxX8mATaxRHQrlwAiWY34tRq/+UBMPakH/GFE7Qs/iky6wi8ZqSYX39 NpQ39TZs+OnFEJEUZsF+Bn44Li2nzxHxLghd7MofcwaiKagtxBjGIV8Wbskd6ozQUZIK Rcr2z9ehtnnE3FgAWyhWcPQFS8eP+bqlQ/o6+4FijFfgPNElHLODGh7GPMnXHkdaxdIf 5Zww== X-Received: by 10.66.8.34 with SMTP id o2mr10246555paa.182.1365094483157; Thu, 04 Apr 2013 09:54:43 -0700 (PDT) Received: from PC ([111.193.205.188]) by mx.google.com with ESMTPS id yz4sm5830974pbc.11.2013.04.04.09.54.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Apr 2013 09:54:42 -0700 (PDT) From: "Leaf Yeh" To: "'Alan DeKok'" , "'Jouni Korhonen'" References: <515D7B4D.7090201@deployingradius.com> In-Reply-To: <515D7B4D.7090201@deployingradius.com> Date: Fri, 5 Apr 2013 00:54:33 +0800 Message-ID: <515db052.24fa440a.4c16.ffff93c2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4xNYeyVSG79PrhReiNj3Ln9NlMtAAFIhyw Content-Language: zh-cn Cc: radext@ietf.org, 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 16:54:44 -0000 Alan - option-len Length of the option-data in octets Q: Can it encode more than 256 octets of RADIUS attributes? If so, what happens then? --- The 'option-len' is 2-octet field. It permit the length of 'option-data' is larger than 256, when the OPTION_RADIUS includes a number of RADIUS attributes. I think the RADIUS attribute here can also be the attribute of Long_Extended_Type newly defined in draft-ietf-radext-radius-extensions-13. Alan - ... Only the attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option' SHOULD be included in the OPTION_RADIUS. That should be a MUST. There's no sense in permitting non-RADIUS traffic in this option. --- Do you want the text to be 'Only the attributes listed in ....MUST be included in ...."? How about turn that 'SHOULD' to be 'should' ? Alan - 8. Security Considerations Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY Using "MAY" here is probably wrong. It should be "may". ---- Accepted. That 'MAY' will update to be 'may'. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Thursday, April 04, 2013 9:08 PM To: Jouni Korhonen Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Jouni Korhonen wrote: > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC > WG. RADEXT WG is solicited for review. We can provide input as part of > the IETF LC once it is started. Remember to CC the RADEXT so we can > keep track of the (possible) comments better. A quick review: 4. DHCPv6 RADIUS option option-len Length of the option-data in octets Q: Can it encode more than 256 octets of RADIUS attributes? If so, what happens then? ... Only the attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option' SHOULD be included in the OPTION_RADIUS. That should be a MUST. There's no sense in permitting non-RADIUS traffic in this option. 8. Security Considerations Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY Using "MAY" here is probably wrong. It should be "may". _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.yeh.sdo@gmail.com Thu Apr 4 10:49:12 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1DE21F8FD3; Thu, 4 Apr 2013 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=1.773, 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 7oo63mYeqiWy; Thu, 4 Apr 2013 10:49:12 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADDF21F8EED; Thu, 4 Apr 2013 10:49:12 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id up7so1553368pbc.29 for ; Thu, 04 Apr 2013 10:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=fnd0HqJLfYaqKrV+2Zsir0EoBZPda+zT6CMKIO/MyJM=; b=MR3et63OkPab9DiMJtOwBZW2kZPqH3Bda0Am/uOLFiCVbtdsLozn3RB/07ZRjbJluQ yAppXD6rly2XfQJg7hM4JCPIQJzjRTm0IKyZ28pozp38vlYBeWunHh6RYA1LLHG7vf8m mqs0+MxSaMOXoVWPpjeBbuDjrDgJa7VMeYRgcifqFyENClUdgQktwDd0lA8YZTmTc7Nu yBzjyNk4Pj86RJmw90hxqdwWjYFemJWXVDxxmCkzDTFKWrk7s1sWV+/f5uKZdzjjZP48 FBUW2YTfDHgQBHSIII0V0A3HSlkVV8/a0dm7U16lQFJKTI21q4jBV75MOwXJXj53TPHz 0jPQ== X-Received: by 10.67.1.39 with SMTP id bd7mr10453929pad.194.1365097751804; Thu, 04 Apr 2013 10:49:11 -0700 (PDT) Received: from PC ([111.193.205.188]) by mx.google.com with ESMTPS id yz4sm5980959pbc.11.2013.04.04.10.49.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Apr 2013 10:49:11 -0700 (PDT) From: "Leaf Yeh" To: "'Jim Schaad'" , "'Alan DeKok'" , "'Jouni Korhonen'" References: <515D7B4D.7090201@deployingradius.com> <011701ce3157$8d1c4900$a754db00$@augustcellars.com> In-Reply-To: <011701ce3157$8d1c4900$a754db00$@augustcellars.com> Date: Fri, 5 Apr 2013 01:49:01 +0800 Message-ID: <515dbd17.24fa440a.4c16.ffff9e13@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHeMUCySghpWabMjAXlQ7CQqOxydwChOzqJmKFCjMCAAAPOQA== Content-Language: zh-cn Cc: radext@ietf.org, 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 17:49:12 -0000 Jim - ...however should there be the ability to send vender defined traffic? The VSA (26) has recommended in the proposed IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. (Section 4.1) Do you want more? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, April 05, 2013 1:12 AM To: 'Alan DeKok'; 'Jouni Korhonen' Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Alan DeKok > Sent: Thursday, April 04, 2013 6:08 AM > To: Jouni Korhonen > Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org > Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > > Jouni Korhonen wrote: > > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC > > WG. RADEXT WG is solicited for review. We can provide input as part > > of the IETF LC once it is started. Remember to CC the RADEXT so we > > can keep track of the (possible) comments better. > > A quick review: > > 4. DHCPv6 RADIUS option > > option-len Length of the option-data in octets > > Q: Can it encode more than 256 octets of RADIUS attributes? If so, > what happens then? > > > ... Only the attributes listed in the IANA Registry of 'RADIUS > attributes permitted in DHCPv6 RADIUS option' SHOULD be included in > the OPTION_RADIUS. > > That should be a MUST. There's no sense in permitting non-RADIUS > traffic in > this option. Alan, I have not looked at the registry in question yet, however should there be the ability to send vender defined traffic? Jim > > > > 8. Security Considerations > > Known security vulnerabilities of the DHCPv6 and RADIUS protocol > MAY > > > Using "MAY" here is probably wrong. It should be "may". > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Apr 4 10:50:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61C21F8D1C; Thu, 4 Apr 2013 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 FBxrmeftqqOb; Thu, 4 Apr 2013 10:50:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7567521F8548; Thu, 4 Apr 2013 10:50:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D07132240F53; Thu, 4 Apr 2013 19:49:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rRYt5VSLx1L; Thu, 4 Apr 2013 19:49:46 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 1AB3A224041B; Thu, 4 Apr 2013 19:49:46 +0200 (CEST) Message-ID: <515DBD38.2020607@deployingradius.com> Date: Thu, 04 Apr 2013 13:49:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf Yeh References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> In-Reply-To: <515db052.24fa440a.4c16.ffff93c2@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 17:50:32 -0000 Leaf Yeh wrote: > The 'option-len' is 2-octet field. It permit the length of 'option-data' is > larger than 256, when the OPTION_RADIUS includes a number of RADIUS > attributes. Ah, I didn't see that. It's OK, then. > I think the RADIUS attribute here can also be the attribute of > Long_Extended_Type newly defined in draft-ietf-radext-radius-extensions-13. Sure... or you may want to limit the number of allowed attributes. > > Alan - ... Only the attributes listed in the IANA Registry of 'RADIUS > attributes permitted in DHCPv6 RADIUS option' SHOULD be included in > the OPTION_RADIUS. > That should be a MUST. There's no sense in permitting non-RADIUS traffic > in this option. > --- > > Do you want the text to be 'Only the attributes listed in ....MUST be > included in ...."? How about turn that 'SHOULD' to be 'should' ? I'd say: This option MUST carry RADIUS attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. Alan DeKok. From Ted.Lemon@nominum.com Thu Apr 4 10:59:16 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9686721F95DA; Thu, 4 Apr 2013 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKbcqOstuWD9; Thu, 4 Apr 2013 10:59:16 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 240B821F958A; Thu, 4 Apr 2013 10:59:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUV2/c5o/Ze+OBtdgOjoU6RDCALstud1t@postini.com; Thu, 04 Apr 2013 10:59:16 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 956F5108080; Thu, 4 Apr 2013 10:59:15 -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 892CC19005D; Thu, 4 Apr 2013 10:59:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 10:59:15 -0700 From: Ted Lemon To: Alan DeKok Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: Ac4xNYeyVSG79PrhReiNj3Ln9NlMtAAFIhywABNZngAAAFUWgA== Date: Thu, 4 Apr 2013 17:59:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> In-Reply-To: <515DBD38.2020607@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 17:59:16 -0000 On Apr 4, 2013, at 1:49 PM, Alan DeKok wrote: > This option MUST carry RADIUS attributes listed in the IANA Registry > of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. I don't think that sentence means what you think it means. This would req= uire that these options be sent even if no values for them were configured = on the RADIUS server. From aland@deployingradius.com Thu Apr 4 13:44:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5997C21F8C14; Thu, 4 Apr 2013 13:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZbXunrrOZ3pT; Thu, 4 Apr 2013 13:44:38 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED60721F8556; Thu, 4 Apr 2013 13:44:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B868A2240F53; Thu, 4 Apr 2013 22:44:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fn8FCACWa-V; Thu, 4 Apr 2013 22:44:27 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 46FE12240D8B; Thu, 4 Apr 2013 22:44:27 +0200 (CEST) Message-ID: <515DE629.6070706@deployingradius.com> Date: Thu, 04 Apr 2013 16:44:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ted Lemon References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 20:44:39 -0000 Ted Lemon wrote: > On Apr 4, 2013, at 1:49 PM, Alan DeKok wrote: >> This option MUST carry RADIUS attributes listed in the IANA Registry >> of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. > > I don't think that sentence means what you think it means. This would require that these options be sent even if no values for them were configured on the RADIUS server. It doesn't say the option MUST be present. It doesn't say the option MUST carry ALL of the RADIUS attributes. It tries to say if you choose to use the option, its contents MUST be RADIUS attributes, and nothing else. Alan DeKok. From Ted.Lemon@nominum.com Thu Apr 4 13:49:29 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C363521F85A1; Thu, 4 Apr 2013 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMP3Bu6YGFhx; Thu, 4 Apr 2013 13:49:28 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3464221F85DC; Thu, 4 Apr 2013 13:49:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUV3nVRIBhNUOKZhXdj5jOy9BUf0Ik7x1@postini.com; Thu, 04 Apr 2013 13:49:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 573FA10809F; Thu, 4 Apr 2013 13:49:19 -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 3E66119005D; Thu, 4 Apr 2013 13:49:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 13:49:19 -0700 From: Ted Lemon To: Alan DeKok Thread-Topic: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMXU4e/gVjJrlEkiGtY0x3ZKBYpjG/i2A Date: Thu, 4 Apr 2013 20:49:17 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> In-Reply-To: <515DE629.6070706@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2CB4E1903E51FC499B8E2400F834383B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 20:49:29 -0000 On Apr 4, 2013, at 4:44 PM, Alan DeKok wrote: >> On Apr 4, 2013, at 1:49 PM, Alan DeKok wrote= : >>> This option MUST carry RADIUS attributes listed in the IANA Registry >>> of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. >>=20 > It tries to say if you choose to use the option, its contents MUST be > RADIUS attributes, and nothing else. While it can definitely be read that way, it doesn't exclude other readings= . To do that, perhaps: This option MUST NOT carry RADIUS attributes not listed in the IANA Regist= ry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. When we discussed this in the DHC working group, there was some controversy= as to whether we need to even have such a restriction; I take it that you = agree that there should be such a restriction? From aland@deployingradius.com Thu Apr 4 13:58:33 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FE621F899E; Thu, 4 Apr 2013 13:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqMR10oyTdN6; Thu, 4 Apr 2013 13:58:32 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC2321F8556; Thu, 4 Apr 2013 13:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9747B2240F53; Thu, 4 Apr 2013 22:58:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmOMGnBz5-S1; Thu, 4 Apr 2013 22:58:01 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 4B7FD2240C73; Thu, 4 Apr 2013 22:58:01 +0200 (CEST) Message-ID: <515DE957.1060202@deployingradius.com> Date: Thu, 04 Apr 2013 16:57:59 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ted Lemon References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 20:58:33 -0000 Ted Lemon wrote: > While it can definitely be read that way, it doesn't exclude other readings. To do that, perhaps: > > This option MUST NOT carry RADIUS attributes not listed in the IANA Registry > of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. Positive statements are usually clearer to understand. > When we discussed this in the DHC working group, there was some controversy as to whether we need to even have such a restriction; I take it that you agree that there should be such a restriction? The intention is for the option to carry RADIUS attributes. Making that a requirement rather than a suggestion is a good idea. Alan DeKok. From Ted.Lemon@nominum.com Thu Apr 4 14:04:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866B21F86FA; Thu, 4 Apr 2013 14:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B3-zLP8yL+u; Thu, 4 Apr 2013 14:04:03 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id C3F9721F862A; Thu, 4 Apr 2013 14:04:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUV3qwu/QmZ2bXFd1qJ+XhiOvId1kssSD@postini.com; Thu, 04 Apr 2013 14:04:02 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 6F2FF1080A0; Thu, 4 Apr 2013 14:04:02 -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 6822519005D; Thu, 4 Apr 2013 14:04:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 14:04:02 -0700 From: Ted Lemon To: Alan DeKok Thread-Topic: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMXU4e/gVjJrlEkiGtY0x3ZKBYpjG/i2AgAACboCAAAGvgA== Date: Thu, 4 Apr 2013 21:04:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> In-Reply-To: <515DE957.1060202@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 21:04:03 -0000 On Apr 4, 2013, at 4:57 PM, Alan DeKok wrote: > Positive statements are usually clearer to understand. Yes, and when I read your statement, I understood it to mean the exact oppo= site of what you intended. Easier to understand doesn't help if the state= ment is ambiguous. > The intention is for the option to carry RADIUS attributes. Making > that a requirement rather than a suggestion is a good idea. This isn't what the text says. It says that the option must only carry a = subset of RADIUS attributes; those listed in a special registry. If you don't like the double negative, here's a precise way to say it that = doesn't contain a double negative: This option MUST NOT carry any RADIUS attribute unless it is listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. But what the text that means what you said in the second quote above would = read like this: This option MUST NOT carry any RADIUS attribute unless it is listed in the IANA Registry Radius Types registry in the section titled 'Radius Attribut= e Types'. From jouni.nospam@gmail.com Fri Apr 5 00:19:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4421F86CE; Fri, 5 Apr 2013 00:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 paZ2iAZWenF7; Fri, 5 Apr 2013 00:19:42 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AA15821F8510; Fri, 5 Apr 2013 00:19:41 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so3153084lab.22 for ; Fri, 05 Apr 2013 00:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=k+VnuTUbAHx3dsSO+rz8qiJC7SmLitAElkO5AnAH0fs=; b=kn/6UkaruogVzdnJcyZaGR2VMk2T7uTpD5ieT52MqRxcID0vjfJFme+lvXJ7nQL3Il UX5g9f4jxC1WaueNCjT67Dw919oUtOSobVokfz+9KKahwSho/DwJMsI1OwdbMEBM55/v ilPo0LRTDwH8hlFKDqDV1J4cMm6Pu15RNlMeL4grn3fFnXHQPEo0WY7j0mIL0SY7wTQn 0Ds4D9zAqgWYJ+/CTSbheeeZf6itK9QvlcAfrObHzalilPcY4tMXGJKbGPfRxFvW8f8x h0qvH8pLPbyqKyx6PorYtb16kE3NzJRRMAkfX1omcWYnRQvQiJbnQKqJOQEzUiVBtaGi PO7Q== X-Received: by 10.152.87.243 with SMTP id bb19mr5260590lab.12.1365146380379; Fri, 05 Apr 2013 00:19:40 -0700 (PDT) Received: from [192.168.250.119] ([194.100.71.98]) by mx.google.com with ESMTPS id w6sm2322943lad.5.2013.04.05.00.19.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 00:19:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> Date: Fri, 5 Apr 2013 10:19:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "" , dhcwg , Alan DeKok Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 07:19:43 -0000 On Apr 5, 2013, at 12:04 AM, Ted Lemon wrote: > On Apr 4, 2013, at 4:57 PM, Alan DeKok = wrote: >> Positive statements are usually clearer to understand. >=20 > Yes, and when I read your statement, I understood it to mean the exact = opposite of what you intended. Easier to understand doesn't help if = the statement is ambiguous. >=20 >> The intention is for the option to carry RADIUS attributes. Making >> that a requirement rather than a suggestion is a good idea. >=20 > This isn't what the text says. It says that the option must only = carry a subset of RADIUS attributes; those listed in a special registry. >=20 > If you don't like the double negative, here's a precise way to say it = that doesn't contain a double negative: >=20 > This option MUST NOT carry any RADIUS attribute unless it is = listed in the > IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS = option'. I don't think this is any improvement over the text Alan provided = originally. My suggestion would be: The option-data of OPTION_RADIUS is a list of one or more RADIUS attributes received in the Access-Accept message from the RADIUS server. The OPTION_RADIUS can only contain RADIUS attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. The next question I have is what happens when a relay includes an = attribute that the server does not understand or is not listed in the registry? = There is no versioning thus it is possible that relay and server have a = different understanding what the IANA registry is. Now the text in Section 6 only addresses the case where the server does not understand the DHCP option. - Jouni >=20 > But what the text that means what you said in the second quote above = would read like this: >=20 > This option MUST NOT carry any RADIUS attribute unless it is = listed in the > IANA Registry Radius Types registry in the section titled = 'Radius Attribute Types'. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Fri Apr 5 03:15:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15221F9743; Fri, 5 Apr 2013 03:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=1.182, 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 PwGrDbWNGf7H; Fri, 5 Apr 2013 03:15:12 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id B3A9721F9740; Fri, 5 Apr 2013 03:15:12 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id xa7so1933210pbc.27 for ; Fri, 05 Apr 2013 03:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=Pstwb3DvG18PePUpsyez9O8sipEbFaehH9gq4MRI9lI=; b=w0Pv930FSaN9gABwsTraCURnyPdhcEOJ4PuOdD595a2R2HvrDamtfYgRBdANqaQ+1y CMgo736Dy2KoLhYBnmbdOqfsuQ3I+Nd9dRAn6iazzjGiVjdJsBJcgkId2+pvXHAOK2M9 hJnIl/9cxKz8toKW1YjBkQuLH+2btOHDgGR5qr0FDg1raIHy1TNkawzZJS+unhJKeWqs jtlSrPkFjM2eyS0AwnzNSiaizF9h5p6oVUMwsvvIkza60eOGVoPWs5CN/XVr7+Yg7XwI lK0d9ZGWWZkfNf2M1Q6mWZTD9157p6jdb4SyZbzq6iZ+ZFiqy79Sqj0wcfjkHcKtGKx9 NPRw== X-Received: by 10.66.122.97 with SMTP id lr1mr14237249pab.147.1365156912382; Fri, 05 Apr 2013 03:15:12 -0700 (PDT) Received: from PC ([111.193.205.188]) by mx.google.com with ESMTPS id t5sm13914550pbi.10.2013.04.05.03.15.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Apr 2013 03:15:11 -0700 (PDT) From: "Leaf Yeh" To: "'Peter Deacon'" , References: In-Reply-To: Date: Fri, 5 Apr 2013 18:15:01 +0800 Message-ID: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4xZGO6qHzaALX1QfiJLr6UMIrzDwAApjaQ Content-Language: zh-cn Cc: 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 10:15:13 -0000 Peter - With the DHCPv6 relay forwarding should relays forward attributes it does not know about to server? From my read (section 5) it seems to say attributes are forwarded if the relay validates value which seems to imply it can't forward attributes it does not know about? Good question. I think the point here is the DHCPv6 relay only forward those valid attribute in the registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. If the DHCPv6 server supports OPTION_RADIUS defined here, it should know all the attributes received from the relay. If the DHCPv6 server still does not know the attributes in OPTION_RADIUS, the server just ignore those attributes per the Postel's Law. Peter - The DHCP analogue (RFC 4014 sec 4) lists other attributes just wondering what is different here that makes the attribute lists different ...IPv6 specific company excluded of course. I guess you are talking about the following attributes (in the table of the section 4 in RFC 4014): 1 User-Name (RFC 2865 [3]) 6 Service-Type (RFC 2865) 27 Session-Timeout (RFC 2865) I still have not got the points (or understood the use case) for: a. User-Name : why the User-Name of AAA (or RADIUS) will be necessary to forward the DHCPv6 server; the standard DHCPv6 server sounds never use it before; b. Service-Type : what kind of service-type of AAA (or RADIUS, http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-4 ) will be necessary to forward the DHCPv6 server; c. Session-Timeout : I think the NAS (DHCPv6 relay + RADIUS client) can be the 1st control point of trusted network , it can decide whether to forward the DHCPv6 messages from the client to the server. After the session is timeout, it just stop forward the DHCPv6 messages from the client to the server. This RADIUS attribute also sounds not necessary to forward to the DHCPv6 server. Right? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Peter Deacon Sent: Friday, April 05, 2013 2:44 AM To: radext@ietf.org Cc: draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 On Thu, 4 Apr 2013, Jouni Korhonen wrote: > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC WG. > RADEXT WG is solicited for review. We can provide input as part of the > IETF LC once it is started. Remember to CC the RADEXT so we can keep > track of the (possible) comments better. I like this scheme. Just have two questions. With the DHCPv6 relay forwarding should relays forward attributes it does not know about to server? From my read (section 5) it seems to say attributes are forwarded if the relay validates value which seems to imply it can't forward attributes it does not know about? The DHCP analogue (RFC 4014 sec 4) lists other attributes just wondering what is different here that makes the attribute lists different ...IPv6 specific company excluded of course. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From Ted.Lemon@nominum.com Fri Apr 5 04:43:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1420A21F9767; Fri, 5 Apr 2013 04:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbuGBSXBxtIS; Fri, 5 Apr 2013 04:43:00 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9521F9765; Fri, 5 Apr 2013 04:43:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUV64w9Gzo03tjCPak2KTXLV5be3qJsLf@postini.com; Fri, 05 Apr 2013 04:43:00 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 B8D4A108177; Fri, 5 Apr 2013 04:42:59 -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 AC87919005D; Fri, 5 Apr 2013 04:42:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 04:42:59 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMc3xheg1Y2HRokOypXMokVkn6ZjH9y6A Date: Fri, 5 Apr 2013 11:42:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> In-Reply-To: <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <505BF77EABF0DA4E91BAFC9B71A9B946@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg , Alan DeKok Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 11:43:01 -0000 On Apr 5, 2013, at 3:19 AM, Jouni Korhonen wrote: > The option-data of OPTION_RADIUS is a list of one or more RADIUS > attributes received in the Access-Accept message from the RADIUS > server. The OPTION_RADIUS can only contain RADIUS attributes > listed in the IANA Registry of 'RADIUS attributes permitted in > DHCPv6 RADIUS option'. So you took out the normative language, right? Was that intentional? > The next question I have is what happens when a relay includes an attribu= te > that the server does not understand or is not listed in the registry? The= re > is no versioning thus it is possible that relay and server have a differe= nt > understanding what the IANA registry is. Now the text in Section 6 only > addresses the case where the server does not understand the DHCP option. Good question. I think the right answer is that that RADIUS attribute is = silently ignored, because, as you say, the server might not be up to date. From jouni.nospam@gmail.com Fri Apr 5 05:50:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909E521F9777; Fri, 5 Apr 2013 05:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 sz00tMGHvqY6; Fri, 5 Apr 2013 05:50:44 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2F21F9763; Fri, 5 Apr 2013 05:50:43 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id x11so3730915lbi.29 for ; Fri, 05 Apr 2013 05:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=qKWcUOYooKMuEDY63xPIjXLHD8cr7iEOSENLBMOxOPw=; b=ABfBm5lZhFyr6sjdqMzEC159qDUAns0iJx31uIn7kPyI+S2TBWXEBy5nSda74sV9+b JJm0pXNshrs/1KsalwsOkxos5+5/k3o/boOcZ8brDmWNI1E7kOlEd+tZjo9s7rJ3qrhk /Ik9o9geOQEsLGUv8cjUuhv+QJ6jN5VDf5ktZBByBbc5+c9OqDkmFi9lE3s9bvFxJZ37 e0sNBPyHrQbBm/xzijuXpDpOZ+IzPasFao1vdP8+fbN9eo0CYlBj2I0ukSTa+NAFnQhX ovI9kBSaaKxlLFZvzaTLD4PK1vLi5JNtZpEZfBF1v6/MlL0EhEYX7tyaY69wQBQ6eDNM a8Ww== X-Received: by 10.112.7.10 with SMTP id f10mr5957683lba.126.1365166242551; Fri, 05 Apr 2013 05:50:42 -0700 (PDT) Received: from [192.168.250.119] ([194.100.71.98]) by mx.google.com with ESMTPS id ng6sm5633000lab.2.2013.04.05.05.50.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 05:50:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> Date: Fri, 5 Apr 2013 15:50:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "" , dhcwg , Alan DeKok Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 12:50:44 -0000 On Apr 5, 2013, at 2:42 PM, Ted Lemon wrote: > On Apr 5, 2013, at 3:19 AM, Jouni Korhonen = wrote: >> The option-data of OPTION_RADIUS is a list of one or more RADIUS >> attributes received in the Access-Accept message from the RADIUS >> server. The OPTION_RADIUS can only contain RADIUS attributes >> listed in the IANA Registry of 'RADIUS attributes permitted in >> DHCPv6 RADIUS option'. >=20 > So you took out the normative language, right? Was that intentional? That was intentional. If that is a concern one can always change the "can only" to "MUST". That works too, since the previous sentence already points out that the option contains one or more attributes, not all. >> The next question I have is what happens when a relay includes an = attribute >> that the server does not understand or is not listed in the registry? = There >> is no versioning thus it is possible that relay and server have a = different >> understanding what the IANA registry is. Now the text in Section 6 = only >> addresses the case where the server does not understand the DHCP = option. >=20 > Good question. I think the right answer is that that RADIUS = attribute is silently ignored, because, as you say, the server might not = be up to date. Blindly dropping an attribute might not work in all cases. For example, = in some cases the server might not then be able to provide all information the relay needs.. That is more of a DHCP specification issue but what I would like to see in this I-D is some text pointing out that the server and the relay may have a different idea of the registry and the protocol design need to take that into account. - Jouni >=20 From Ted.Lemon@nominum.com Fri Apr 5 06:12:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B121F9781; Fri, 5 Apr 2013 06:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBvtthUxhxTU; Fri, 5 Apr 2013 06:12:28 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0823521F9780; Fri, 5 Apr 2013 06:12:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUV7Nuz/NQsNMTLeEBg1BCHTX7tVbJivZ@postini.com; Fri, 05 Apr 2013 06:12:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BCEB4108195; Fri, 5 Apr 2013 06:12:27 -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 B19F319005D; Fri, 5 Apr 2013 06:12:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 06:12:27 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMc3xheg1Y2HRokOypXMokVkn6ZjH9y6AgAAS5ACAAAYcAA== Date: Fri, 5 Apr 2013 13:12:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1ADC18F33AA52545BAADE6583215783D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg , Alan DeKok Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 13:12:28 -0000 On Apr 5, 2013, at 8:50 AM, Jouni Korhonen wrote: > Blindly dropping an attribute might not work in all cases. For example, i= n > some cases the server might not then be able to provide all information > the relay needs.. Well, I did say "silently ignored," not "dropped," but yeah. If the serve= r doesn't support that attribute, it's not going to have any effect anyway.= It seems like silently ignoring it is better than dropping the whole mes= sage, although I suppose you could argue the opposite, since a misconfigura= tion of this sort is probably something the administrator wants to fix imme= diately, not discover by accident years later. From tomasz.mrugalski@gmail.com Fri Apr 5 07:16:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3A21F97C8; Fri, 5 Apr 2013 07:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxdYCeV7FmLb; Fri, 5 Apr 2013 07:16:50 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3A21F97AA; Fri, 5 Apr 2013 07:16:49 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so1426403eaj.21 for ; Fri, 05 Apr 2013 07:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=kvcUpe8OcUbg1yBLu9s1lOZPNi1097CCwuuR9Rfsni8=; b=fl3te9NBPUQ+By30DCqMFnNw/MnAimVQUd7SXxPrkW1syNILVHe5+g8/+NbIzdyfgu 5OspbDc2CVdauRCSxLtq/JqheeHwz6wd+JhdXy+bKkD3B7khn9ZC9P49uKpTEwjB+/3O eaHupdKhfX8o+tnfpg2LLBmXRSmm2XlGcsPC7ICbuuxg9pO7rwYhGR3AZyH+gsASx9UW ZqsRJ9R0gmN7uDsjPy9s8gGX2jxPnsjwgBSMAW78dHFqHUdJc64DW7RkAvJMm6eCN2mM JAMEZtrs31pPuLB+LTPVMYr4UQmvSwSEGlkp+jUD/bb9Zly82rm12YJo9f6n/8m2ObbE ioMA== X-Received: by 10.14.179.5 with SMTP id g5mr19998420eem.41.1365171408917; Fri, 05 Apr 2013 07:16:48 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:887e:68e1:7d5e:1422? ([2001:470:6061:1:887e:68e1:7d5e:1422]) by mx.google.com with ESMTPS id d47sm15705304eem.9.2013.04.05.07.16.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 07:16:44 -0700 (PDT) Message-ID: <515EDCC7.5010708@gmail.com> Date: Fri, 05 Apr 2013 16:16:39 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130405161639166 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 14:16:50 -0000 On 05.04.2013 15:12, Ted Lemon wrote: > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen > wrote: >> Blindly dropping an attribute might not work in all cases. For >> example, in some cases the server might not then be able to provide >> all information the relay needs.. > > Well, I did say "silently ignored," not "dropped," but yeah. If the > server doesn't support that attribute, it's not going to have any > effect anyway. It seems like silently ignoring it is better than > dropping the whole message, although I suppose you could argue the > opposite, since a misconfiguration of this sort is probably something > the administrator wants to fix immediately, not discover by accident > years later. Anyway, dropping the whole message is definitely too radical here. We have 3 options when server receives an unknown attribute: a) ignore just the unknown attribute b) ignore the whole radius option c) ignore the whole message I think we have an agreement that a) is the way to go. At least that's what I strongly recommend. Also, depending on server implementation, it is quite likely that the server will parse unknown attributes and handle them in some generic way, e.g. hex string. This is what some implementations do with unknown DHCPv6 options and I imagine similar approach can be taken with RADIUS attributes. Of course, such a behaviour is strictly implementation specific, so there's no need to put anything about it in the spec. So whether the attribute is "unknown" or not may be a bit blurry definition sometimes. "Server MAY ignore received RADIUS attributes that it does not support." seems like a reasonable text here. Some implementors will ignore unknown attribute, some may produce a warning and some my try to handle it in a generic way. Tomek From Ted.Lemon@nominum.com Fri Apr 5 07:27:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A10C21F97D0; Fri, 5 Apr 2013 07:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yJI0pjmNO6I; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 935F921F97B6; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUV7faWWlOSpc3c9slrXFrKCWDQY/uiqQ@postini.com; Fri, 05 Apr 2013 07:27:53 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 178F61B8225; Fri, 5 Apr 2013 07:27:53 -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 0DAAA19005D; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 07:27:53 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMc3xheg1Y2HRokOypXMokVkn6ZjH9y6AgAAS5ACAAAYcAIAAEe+AgAADJAA= Date: Fri, 5 Apr 2013 14:27:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> <515EDCC7.5010708@gmail.com> In-Reply-To: <515EDCC7.5010708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <2E75FA08C390B04A814EB664E28B07C1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg , "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 14:27:54 -0000 On Apr 5, 2013, at 10:16 AM, Tomek Mrugalski w= rote: > "Server MAY ignore received RADIUS attributes that it does not support." > seems like a reasonable text here. Some implementors will ignore unknown > attribute, some may produce a warning and some my try to handle it in a > generic way. Generally speaking, this sort of language is a recipe for attack. I think= the draft should just say that the administrator should be able to update = the list of acceptable options. From aland@deployingradius.com Fri Apr 5 07:28:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9371821F970E; Fri, 5 Apr 2013 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 8kHKIDcpy0BH; Fri, 5 Apr 2013 07:28:49 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4F21F9701; Fri, 5 Apr 2013 07:28:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 20B9A22410F7; Fri, 5 Apr 2013 16:28:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMjtRT-DDiEo; Fri, 5 Apr 2013 16:28:30 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 439B02240F50; Fri, 5 Apr 2013 16:28:30 +0200 (CEST) Message-ID: <515EDF8C.90104@deployingradius.com> Date: Fri, 05 Apr 2013 10:28:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ted Lemon References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> <515EDCC7.5010708@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg , "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 14:28:49 -0000 Ted Lemon wrote: > Generally speaking, this sort of language is a recipe for attack. I think the draft should just say that the administrator should be able to update the list of acceptable options. That's probably best. From peterd@iea-software.com Fri Apr 5 09:11:37 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A543121F97AE; Fri, 5 Apr 2013 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 ibqEdphDfMiV; Fri, 5 Apr 2013 09:11:37 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id C2BB921F976F; Fri, 5 Apr 2013 09:11:36 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 09:11:36 -0700 Date: Fri, 5 Apr 2013 09:11:31 -0700 (Pacific Daylight Time) From: Peter Deacon To: Leaf Yeh In-Reply-To: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> Message-ID: References: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 05 Apr 2013 09:14:11 -0700 Cc: radext@ietf.org, 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 16:11:37 -0000 On Fri, 5 Apr 2013, Leaf Yeh wrote: > Peter - With the DHCPv6 relay forwarding should relays forward attributes it > does not know about to server? From my read (section 5) it seems to say > attributes are forwarded if the relay validates value which seems to imply > it can't forward attributes it does not know about? > Good question. I think the point here is the DHCPv6 relay only forward > those valid attribute in the registry of 'RADIUS attributes permitted in > DHCPv6 RADIUS option'. If the DHCPv6 server supports OPTION_RADIUS > defined here, it should know all the attributes received from the relay. > If the DHCPv6 server still does not know the attributes in > OPTION_RADIUS, the server just ignore those attributes per the Postel's > Law. Hi Leaf, Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 servers in number and vendors involved. It might be difficult to ever add new attributes in production as you would have to touch all relays to allow a new attribute to pass. My guess VSAs would likely end up filling any gaps anyway. > Peter - The DHCP analogue (RFC 4014 sec 4) lists other attributes just > wondering what is different here that makes the attribute lists different > ...IPv6 specific company excluded of course. > I guess you are talking about the following attributes (in the table of the > section 4 in RFC 4014): > 1 User-Name (RFC 2865 [3]) > 6 Service-Type (RFC 2865) > 27 Session-Timeout (RFC 2865) > I still have not got the points (or understood the use case) for: > a. User-Name : why the User-Name of AAA (or RADIUS) will be necessary to > forward the DHCPv6 server; the standard DHCPv6 server sounds never use it > before; > b. Service-Type : what kind of service-type of AAA (or RADIUS, > http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-4 > ) will be necessary to forward the DHCPv6 server; > c. Session-Timeout : I think the NAS (DHCPv6 relay + RADIUS client) can be > the 1st control point of trusted network , it can decide whether to forward > the DHCPv6 messages from the client to the server. After the session is > timeout, it just stop forward the DHCPv6 messages from the client to the > server. This RADIUS attribute also sounds not necessary to forward to the > DHCPv6 server. Right? Yes, I can't think of much either. User-Name might be used to correlate any user specific settings stored in DHCP server or just logging purposes to understand end user associated with DHCP queries. regards, Peter From Ted.Lemon@nominum.com Fri Apr 5 09:18:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7EA21F9838; Fri, 5 Apr 2013 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H3ieUuu4kCm; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4621F9835; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUV75PIz5P8RUE7qATDSMUtovzRsvzAei@postini.com; Fri, 05 Apr 2013 09:18:04 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 463F81081C0; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3A9C319005D; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 09:18:04 -0700 From: Ted Lemon To: Peter Deacon Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: Ac4xZGO6VSG79PrhReiNj3Ln9NlMtAAApjaQADr6/IAAADrcAA== Date: Fri, 5 Apr 2013 16:18:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com> References: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <05F797F04784824AB252DF5AB6BD323A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 16:18:06 -0000 On Apr 5, 2013, at 12:11 PM, Peter Deacon wrote: > Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6= servers in number and vendors involved. It might be difficult to ever add= new attributes in production as you would have to touch all relays to allo= w a new attribute to pass. My guess VSAs would likely end up filling any g= aps anyway. What's a VSA? Should the document specify that the list of attributes to = forward be customizable by the administrator? I think the main purpose that the list of options not to forward serves is = to have a default setting, and to exclude on a protocol specification level= the use of options that we don't specifically intend be used; if an admini= strator configures some option that's not on the list, I think that's harml= ess. From peterd@iea-software.com Fri Apr 5 11:25:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3493921F984E; Fri, 5 Apr 2013 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 G47LwWoMra8H; Fri, 5 Apr 2013 11:25:19 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 932BF21F9849; Fri, 5 Apr 2013 11:25:19 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 11:25:19 -0700 Date: Fri, 5 Apr 2013 11:25:14 -0700 (Pacific Daylight Time) From: Peter Deacon To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com> Message-ID: References: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Fri, 05 Apr 2013 11:53:14 -0700 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 18:25:20 -0000 On Fri, 5 Apr 2013, Ted Lemon wrote: > On Apr 5, 2013, at 12:11 PM, Peter Deacon wrote: >> Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 servers in number and vendors involved. It might be difficult to ever add new attributes in production as you would have to touch all relays to allow a new attribute to pass. My guess VSAs would likely end up filling any gaps anyway. > What's a VSA? Should the document specify that the list of attributes > to forward be customizable by the administrator? Hi Ted Lemon, The configuration options sound good. VSA = Vendor Specific Attribute (Vendor-Specific in table sec 4.1) regards, Peter From denghui02@gmail.com Sat Apr 6 06:02:47 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB121F8E06 for ; Sat, 6 Apr 2013 06:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 uZF5S631FZin for ; Sat, 6 Apr 2013 06:02:45 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5B21F8BF4 for ; Sat, 6 Apr 2013 06:02:45 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id cz11so2496303qeb.1 for ; Sat, 06 Apr 2013 06:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hijJmCUO1JvnLaqvPs+OW9edJL9Lrv0FGdwORJc0fFQ=; b=jrmPrXkccoj/p2dE+NWHHfo6Ds+cbGBIblduyVz1PNEMBAtH9DgEHzG5OTJukNNLNX Bqc5PdJlWxt88c1D8DLTSOyZzsQTfz7G4Ae6KNglbkkcA4IdMzuHoGN+yQq8gw+5B5sf ugnrkV/BsAi2FxNW/g7urvLKum6lpoNW7bwIaQhWVumcDiHsCw3bqh959uiSl3JrDhaH SIiZbWFhPeeW/LWThNRArCz0Dy1oub7Wtgczhg+zmBCro90eo+hD3T0sgts9ruEJ+mB5 1ARNIz0eeIMG8ZW4NK6N6cww0vZSySgqCt2lCX1L6Z3SRPqYZLpkohBXaIE4Mk55oU8I J0Fw== MIME-Version: 1.0 X-Received: by 10.229.145.4 with SMTP id b4mr2124590qcv.17.1365253364924; Sat, 06 Apr 2013 06:02:44 -0700 (PDT) Received: by 10.49.95.133 with HTTP; Sat, 6 Apr 2013 06:02:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Apr 2013 21:02:44 +0800 Message-ID: From: Hui Deng To: VithalPrasad Gaitonde Content-Type: multipart/alternative; boundary=f46d04478ab3d849e404d9b0d19a Cc: "" , Andre Kostur Subject: Re: [dhcwg] DHCP in virtualized networks/Multi-tenant DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 13:02:47 -0000 --f46d04478ab3d849e404d9b0d19a Content-Type: text/plain; charset=ISO-8859-1 I guess that DHCP runing over a VM sits on a data center. -Hui 2013/4/3 VithalPrasad Gaitonde > Adding the working group. Did a reply to sender out of oversight. > > > On Wed, Apr 3, 2013 at 12:06 AM, VithalPrasad Gaitonde wrote: > >> I am referring to environments where tenant VMs use their own IP space >> (Bring Your Own IP) in an IaaS cloud environment with GRE or VXLAN being >> used for network virtualization. The problems that I see are - >> 1. How does DHCP broadcast messages in the tenant network get relayed to >> multi-tenant DHCP server >> 2. How does DHCP server determine which tenant IP space to lease an IP >> address (and options) from >> >> Thanks, >> Prasad >> >> >> On Tue, Apr 2, 2013 at 12:39 AM, Andre Kostur wrote: >> >>> On Mon, Apr 1, 2013 at 11:59 AM, VithalPrasad Gaitonde >>> wrote: >>> > Is there any guidance (BCP ?) on using DHCP in network virtualization >>> > environments. Alternatively, is there interest in the working group on >>> > arriving at a guidance if there isn't one already. >>> >>> It would help if you clarified what you mean by "network >>> virtualization environments". What sort of issues do you see >>> happening? >>> >>> -- >>> Andre Kostur >>> >> >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --f46d04478ab3d849e404d9b0d19a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I guess that DHCP runing over a VM sits on a data cen= ter.
=A0
-Hui

2013/4/3 VithalPrasad Gaitonde <gvithal@gm= ail.com>
Adding the working group. D= id a reply to sender out of oversight.

On Wed, Apr 3, 2013 at 12:06 AM, VithalPrasad Gaitonde &l= t;gvithal@gmail.com<= /a>> wrote:
I am referring to environments where tena= nt VMs use their own IP space (Bring Your Own IP) in an IaaS cloud environm= ent with GRE or VXLAN being used for network virtualization. The problems t= hat I see are -
1. How does DHCP broadcast messages in the tenant network get relayed to mu= lti-tenant DHCP server
2. How does DHCP server determine which te= nant IP space to lease an IP address (and options) from

Thanks,
Prasad
<= div>


On Tue, A= pr 2, 2013 at 12:39 AM, Andre Kostur <akostur@incognito.com> wrote:
On Mon, Apr 1, 2013 at 11:59 AM, VithalPrasad Ga= itonde
<gvithal@gmail.co= m> wrote:
> Is there any guidance (BCP ?) on using DHCP in network virtualization<= br> > environments. Alternatively, is there interest in the working group on=
> arriving at a guidance if there isn't one already.

It would help if you clarified what you mean by "network virtualization environments". =A0What sort of issues do you see
happening?

--
Andre Kostur



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


--f46d04478ab3d849e404d9b0d19a-- From sunqi.thu@gmail.com Sun Apr 7 22:23:56 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88BB21F85F3 for ; Sun, 7 Apr 2013 22:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aX6CCvbHTRQ for ; Sun, 7 Apr 2013 22:23:55 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 021F421F85D8 for ; Sun, 7 Apr 2013 22:23:54 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z13so5350434lbh.13 for ; Sun, 07 Apr 2013 22:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=10rO1szyT+aodw0U83lH/p2J/yLw8Owss7AIXvlJKsE=; b=yyP+WRymiElQbRetqEuE/sCe4Nwr1XnYA8jBHj2QATcKHR0Ao3C+dyfW7hUToEvLOx T8TXfNAo45Pp5IfnY+Ois49h/Sk5v/jtwxp6qNZvEYcN1o5JwOkwxt3uO5n13LDOGC67 OwOaHD9RUclQeE19StdvyhcdnVTwoFzgBwBwpgcvX5ee9qsxbgqhK7DINju3V5ixHjEo wuL/JzbCYPGNoHnd9Pox/p3c+Qe/wEt1BnHnjtpA3PvPQf3oWH1hmBfT5rxI6f7728N+ f1VrZuGb7dKdleP8/tfLk3OA1SMiYOnKwwzNnCjdXQ7K9PfIgkLwH+QwTg+0JKGy9nUu wYEQ== MIME-Version: 1.0 X-Received: by 10.112.49.165 with SMTP id v5mr10796721lbn.67.1365398633815; Sun, 07 Apr 2013 22:23:53 -0700 (PDT) Received: by 10.112.5.202 with HTTP; Sun, 7 Apr 2013 22:23:53 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> Date: Mon, 8 Apr 2013 13:23:53 +0800 Message-ID: From: Qi Sun To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=bcaec554de348ba84904d9d2a4be Cc: dhcwg Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 05:23:56 -0000 --bcaec554de348ba84904d9d2a4be Content-Type: text/plain; charset=ISO-8859-1 Dear Bernie, Thank you for your thorough review of the draft. Please see inline :) Best Regards, Qi On Thu, Apr 4, 2013 at 2:04 AM, Bernie Volz (volz) wrote: > > This document (I believe) intends to update RFC 3315, but does not > indicate that in the header. [Qi] Yes, the draft is meant to update RFC 3315 about the handling of unknown messages. We will make it clear in Abstract & Introduction parts. > This might be something to debate, but I would think it may want to make > some explicit changes to RFC 3315. For example, RFC 3315 section 20.1 > states: > > When a relay agent receives a > valid message to be relayed, it constructs a new Relay-forward > message. > > So what was meant by 'valid' message? Here, I suspect you want to clarify > this and perhaps state everything but a Relay-Reply (at least at the > present time, future documents might change this if there are messages > intended for the Relay -- such as the new message proposed by > draft-scskf-dhc-dhcpv4-over-dhcpv6). That in itself may create a slightly > odd situation. > [Qi] We will try to make the changes to RFC 3315 more specific and address these related issues. > Some other nits: > - Section 2, "...in RFC 3315 about [the case that] what a relay". "The > case that" can be removed. > - Section 3, "leverage the information" ... what information? > [Qi] We use the word "information" intends to say a relay agent is able to tell that the Relay-reply message is for uplink while the Relay-forward and other messages are for downlink. Maybe we need more efforts to make it clearer. > - Section 5, "attacker can interference ... inject fake" ... attacker can > interfere ... by injecting? Note also that the client and server attacks > for invalid message type code packets already exists for "on-link" attacks > too. > [Qi] What we would like to express is that an attacker can interfere the DHCP process by constructing a packet with an unknown message type code (considering the relay agent will relay unknown message). > - Section 5, "yet no known vulnerabilities exist". I'm not sure it is a > good idea to claim this; perhaps best to just drop those words. > [Qi] We would remove those words. > - The document makes use of 2119 keywords yet does not indicate so. > - All RFC 3315 usages should likely be to the reference. > [Qi] We will make modifications accordingly. > > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Tomek Mrugalski > Sent: Wednesday, April 03, 2013 1:26 PM > To: dhcwg > Subject: [dhcwg] Adoption call on > draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 > > Hi all, > This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during > last IETF meeting. We were somewhat surprised to note that RFC3315 does not > clarify how the relays should handle message types that they do not > recognize. This draft clarifies that unknown messages should be relayed as > usual. > > Authors requested adoption call on > draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being > initiated to confirm whether there is WG consensus to adopt this work as > DHC WG draft. Please state whether or not you're in favor of the adoption > by replying to this mail. > If you are not in favor, please also state your objections in your > response. This adoption call will complete on 2013-04-17. > > Regards, > Bernie & Tomek > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --bcaec554de348ba84904d9d2a4be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Bernie,

Thank you for your thorough review of the d= raft. Please see inline :)

Best Regards,
Qi

On Thu, Apr 4, 2013 at 2:04 AM, Berni= e Volz (volz) <volz@cisco.com> wrote:

This document (I believe) intends to update RFC 3315, but does not indicate= that in the header.

[Qi] Yes, the draft i= s meant to update RFC 3315 about the handling of unknown messages. We will = make it clear in Abstract & Introduction parts.
=A0
This might be something to deb= ate, but I would think it may want to make some explicit changes to RFC 331= 5. For example, RFC 3315 section 20.1 states:

=A0 =A0When a relay agent receives a
=A0 =A0valid message to be relayed, it constructs a new Relay-forward
=A0 =A0message.

So what was meant by 'valid' message? Here, I suspect you want to c= larify this and perhaps state everything but a Relay-Reply (at least at the= present time, future documents might change this if there are messages int= ended for the Relay -- such as the new message proposed by draft-scskf-dhc-= dhcpv4-over-dhcpv6). That in itself may create a slightly odd situation.

[Qi] We will try to make the changes to RF= C 3315 more specific and address these related issues.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Some other nits:
- Section 2, "...in RFC 3315 about [the case that] what a relay".= "The case that" can be removed.
- Section 3, "leverage the information" ... what information?
=

[Qi] We use the word "information&quo= t; intends to say a relay agent is able to tell that the Relay-reply messag= e is for uplink while the Relay-forward and other messages are for downlink= . Maybe we need more efforts to make it clearer.
=A0
- Section 5, "attacker can interference ... inject fake" ... atta= cker can interfere ... by injecting? Note also that the client and server a= ttacks for invalid message type code packets already exists for "on-li= nk" attacks too.

[Qi] What we would like to express is that= an attacker can interfere the DHCP process by constructing a packet with a= n unknown message type code (considering the relay agent will relay unknown= message).=A0
=A0
- Section 5, "yet no known vulnerabilities exist". I'm not su= re it is a good idea to claim this; perhaps best to just drop those words.<= br>

[Qi] We would remove those words.
=A0
- The document makes use of 2119 keywords yet does not indicate so.
- All RFC 3315 usages should likely be to the reference.
[Qi] We will make modifications accordingly.
=A0



-----Original Message-----
From: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 03, 2013 1:26 PM
To: dhcwg
Subject: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315upda= te-00

Hi all,
This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during la= st IETF meeting. We were somewhat surprised to note that RFC3315 does not c= larify how the relays should handle message types that they do not recogniz= e. This draft clarifies that unknown messages should be relayed as usual.
Authors requested adoption call on
draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being initiate= d to confirm whether there is WG consensus to adopt this work as DHC WG dra= ft. Please state whether or not you're in favor of the adoption by repl= ying to this mail.
If you are not in favor, please also state your objections in your response= . This adoption call will complete on 2013-04-17.

Regards,
Bernie & Tomek


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

--bcaec554de348ba84904d9d2a4be-- From jouni.nospam@gmail.com Mon Apr 8 00:31:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4321F854F; Mon, 8 Apr 2013 00:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.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 D+nKkf4aa9hk; Mon, 8 Apr 2013 00:31:54 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 63FEC21F854E; Mon, 8 Apr 2013 00:31:53 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo12so193396lab.24 for ; Mon, 08 Apr 2013 00:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:message-id:mime-version:subject:date :references:cc:to:x-mailer; bh=REYLf+RVW0n4IVeE5Y10fQF/jLokEVSbRIR02KY5D/8=; b=y52loBgEfe88ygg3xp8JamVlOvBGKCXmsyXyqubMMC5RtzsjQOIDHSRDFa/JBo8zO8 p7QleBbj86XOyjPctjkmIElGYfYC0zQmnHf+g6KSw7sSoIiENyjwkqkaBLoC9uDDyo0C rjyz4UtNvmx0jG9oLOIxaaEUd9op9g38Gw+s1qntiyotiB2Dy8prQQ+jr/9dVtuz9Fas KiTG4Qrk9AcyP+7njedIoGLPlNsutf89yYRCihUJXpBA45gpCczXQf+vojKqJ5nSQiCc 7XeAQV0nd655Bi94GIK8eyRD8Orriy2TooaEG4zwjnphCwvgKv37BC+rw5Zf1DIahwrL JqCA== X-Received: by 10.152.109.112 with SMTP id hr16mr11171361lab.38.1365406312282; Mon, 08 Apr 2013 00:31:52 -0700 (PDT) Received: from [192.168.250.228] ([194.100.71.98]) by mx.google.com with ESMTPS id c7sm10136147lbe.6.2013.04.08.00.31.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 00:31:50 -0700 (PDT) From: Jouni Korhonen Content-Type: multipart/alternative; boundary="Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Mon, 8 Apr 2013 10:31:49 +0300 References: To: "" X-Mailer: Apple Mail (2.1503) Cc: dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 07:31:54 -0000 --Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Seems that I forgot to CC mailing lists. - Jouni Begin forwarded message: > From: jouni korhonen > Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > Date: April 5, 2013 7:37:47 PM GMT+03:00 > To: Tomek Mrugalski >=20 >=20 > 5.4.2013 17.16 "Tomek Mrugalski" = kirjoitti: > > > > On 05.04.2013 15:12, Ted Lemon wrote: > > > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen = > > > wrote: > > >> Blindly dropping an attribute might not work in all cases. For > > >> example, in some cases the server might not then be able to = provide > > >> all information the relay needs.. > > > > > > Well, I did say "silently ignored," not "dropped," but yeah. If = the > > > server doesn't support that attribute, it's not going to have any > > > effect anyway. It seems like silently ignoring it is better than > > > dropping the whole message, although I suppose you could argue the > > > opposite, since a misconfiguration of this sort is probably = something > > > the administrator wants to fix immediately, not discover by = accident > > > years later. > > Anyway, dropping the whole message is definitely too radical here. = We >=20 > I was not suggesting dropping the message. I said "blindly dropping an = attribute".. which is somewhat different. I am fine with a) but my point = was that it is possible in future when new attributes get added to = registry server silently discarding attributes may lead to a situation = where the server fails to provide enough information back to relay. This = needs to be taken into account when defining DHCP extensions relying on = this I-D and the established registry. >=20 > Jouni >=20 > > have 3 options when server receives an unknown attribute: > > a) ignore just the unknown attribute > > b) ignore the whole radius option > > c) ignore the whole message > > > > I think we have an agreement that a) is the way to go. At least = that's > > what I strongly recommend. > > > > Also, depending on server implementation, it is quite likely that = the > > server will parse unknown attributes and handle them in some generic > > way, e.g. hex string. This is what some implementations do with = unknown > > DHCPv6 options and I imagine similar approach can be taken with = RADIUS > > attributes. Of course, such a behaviour is strictly implementation > > specific, so there's no need to put anything about it in the spec. > > So whether the attribute is "unknown" or not may be a bit blurry > > definition sometimes. > > > > "Server MAY ignore received RADIUS attributes that it does not = support." > > seems like a reasonable text here. Some implementors will ignore = unknown > > attribute, some may produce a warning and some my try to handle it = in a > > generic way. > > > > Tomek > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Seems = that I forgot to CC mailing lists.

- = Jouni

Begin forwarded message:

From: jouni korhonen = <jouni.nospam@gmail.com>
<= /span>
Subject: Re: [dhcwg] [radext] = draft-ietf-dhc-dhcpv6-radius-opt-10
Date: April 5, 2013 = 7:37:47 PM GMT+03:00
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com&= gt;


5.4.2013 17.16 "Tomek Mrugalski" <tomasz.mrugalski@gmail.com&= gt; kirjoitti:
>
> On 05.04.2013 15:12, Ted Lemon wrote:
> > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <jouni.nospam@gmail.com>
> > wrote:
> >> Blindly dropping an attribute might not work in all cases. = For
> >> example, in some cases the server might not then be able = to provide
> >> all information the relay needs..
> >
> > Well, I did say "silently ignored," not "dropped," but yeah. =   If the
> > server doesn't support that attribute, it's not going to have = any
> > effect anyway.   It seems like silently ignoring it is = better than
> > dropping the whole message, although I suppose you could argue = the
> > opposite, since a misconfiguration of this sort is probably = something
> > the administrator wants to fix immediately, not discover by = accident
> > years later.
> Anyway, dropping the whole message is definitely too radical here. = We

I was not suggesting dropping the message. I said = "blindly dropping an attribute".. which is somewhat different. I am fine = with a) but my point was that it is possible in future when new = attributes get added to registry server silently discarding attributes = may lead to a situation where the server fails to provide enough = information back to relay. This needs to be taken into account when = defining DHCP extensions relying on this I-D and the established = registry.

Jouni

> have 3 options = when server receives an unknown attribute:
> a) ignore just the unknown attribute
> b) ignore the whole radius option
> c) ignore the whole message
>
> I think we have an agreement that a) is the way to go. At least = that's
> what I strongly recommend.
>
> Also, depending on server implementation, it is quite likely that = the
> server will parse unknown attributes and handle them in some = generic
> way, e.g. hex string. This is what some implementations do with = unknown
> DHCPv6 options and I imagine similar approach can be taken with = RADIUS
> attributes. Of course, such a behaviour is strictly = implementation
> specific, so there's no need to put anything about it in the = spec.
> So whether the attribute is "unknown" or not may be a bit = blurry
> definition sometimes.
>
> "Server MAY ignore received RADIUS attributes that it does not = support."
> seems like a reasonable text here. Some implementors will ignore = unknown
> attribute, some may produce a warning and some my try to handle it = in a
> generic way.
>
> Tomek
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/= mailman/listinfo/dhcwg


= --Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA-- From tomasz.mrugalski@gmail.com Mon Apr 8 05:33:09 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FDF21F93DB for ; Mon, 8 Apr 2013 05:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 hZWxTPpo2F1p for ; Mon, 8 Apr 2013 05:33:07 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 056BA21F93D8 for ; Mon, 8 Apr 2013 05:33:06 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id q14so2219163eaj.36 for ; Mon, 08 Apr 2013 05:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=6XxcFR/mR6o/DyedBdtt0P/DsxZ+6m91y8Ql7Sp8iyo=; b=aTneHaPdPpFRcymMulLNeyNROAjdQOcgrJGGIvDLMUxzovNbFFjK1CRMUpuMA3kg26 190+27vFAypW252/iE+W23FPveKKmJ7fSHEMNgWjlEe5UqeNJidZssAdBNFoFcfjWl3d m/mW113exROU9oFvkkbGTQ2Cb04Vdv9op3pifab7b8OSrWxo5VHnkIiVMF0cBMrOII3b UaLK3RtqVQg3zcm2EooeapX0DdYKlTBhRVCBhOlysGNA/3oxfBrQ2Ni8smaXtpvgJaKI Jb1OvisSC4BuMKpVN+uaDPI02AycbOsfys5yFwW0V39Dcg5Q5dj07BbUkgCA8Le1YhrQ q2kA== X-Received: by 10.14.3.70 with SMTP id 46mr48785875eeg.2.1365424381628; Mon, 08 Apr 2013 05:33:01 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id d47sm31779727eem.9.2013.04.08.05.32.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 05:33:00 -0700 (PDT) Message-ID: <5162B8F8.3030908@gmail.com> Date: Mon, 08 Apr 2013 14:32:56 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> X-TagToolbar-Keys: D20130408143256786 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:33:09 -0000 On 24.03.2013 21:25, Bernie Volz (volz) wrote: > Folks, the authors of draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 > > feel it's ready for a WGLC. There's been discussion and comment > already, but more eyes on this work are definitely needed to advance it. > > Please review the draft and indicate whether or not you feel it is ready > to be published. We have been getting very anemic responses to working > group messages recently. Your response matters, so please do respond. > > Tomek and I will evaluate consensus after April 8, 2013. Today is the last day of this WGLC and the response has been abysmal for now. Consider this mail a last reminder. Bernie and I will assess the results tomorrow. So far it seems that will be an easy decision. Tomek From Ted.Lemon@nominum.com Mon Apr 8 06:17:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441AE21F93D9 for ; Mon, 8 Apr 2013 06:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 414oO64YrlOC for ; Mon, 8 Apr 2013 06:17:19 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FC21F93CB for ; Mon, 8 Apr 2013 06:17:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUWLDX4Rp3pZjSi6WXrvab+UrfZ7vcDaF@postini.com; Mon, 08 Apr 2013 06:17:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 356481B8587 for ; Mon, 8 Apr 2013 05:40:35 -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 2A2DD190061; Mon, 8 Apr 2013 05:40:35 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 05:40:35 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac4ozYfaibHYbpaWSZS5v8sktAaRTwLwlbAAAABEPwA= Date: Mon, 8 Apr 2013 12:40:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> In-Reply-To: <5162B8F8.3030908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <186AB0F663D34B4197370C94B510EAB8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:17:20 -0000 On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski wr= ote: > Today is the last day of this WGLC and the response has been abysmal for > now. This is a bit frustrating=97I think the problem that the prefix pool option= is addressing is a real problem, but it's so leading edge that I don't thi= nk a lot of people have really thought about it. I think it's a problem t= hat we ought to solve, but if nobody is willing to think about it, it's que= stionable that it's a good idea for the working group to push the solution. How many people have actually reviewed the draft at this point and understa= nd the problem it's trying to solve? From tomasz.mrugalski@gmail.com Mon Apr 8 06:39:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B883E21F8EE1 for ; Mon, 8 Apr 2013 06:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 UMaU0J4mN+ZA for ; Mon, 8 Apr 2013 06:39:04 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A508A21F8BF4 for ; Mon, 8 Apr 2013 06:39:03 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so2253272eaj.7 for ; Mon, 08 Apr 2013 06:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=2tOMSex3xaTMPEt6kprLddmfPH7dp0PirdC6kgMA808=; b=SrjqgeIYqyaRnS6iG84ET1c8r/nxLP0ehczLvsw0ytkb3JBVA4EwMHiH+VUYWshq/K ntOD3rMKki50nix7olbeqfHcgvRfBYLsmDJi8v4zUTeeWjRIoXXdtIY5nrhqksR5Ohph PVkkzki0Xf99k8veBqO2i2Xm2uejNoESy5YlJX7yHnpIBsn+DXRjtWgHcw/zvbKLj75+ vc8FypuwhiyuM8WOms5QjNxNcUYBkGs56XYdMyVD4O/cEhZ73gGe+W/7Jbi07Rhah28y GBvVFmPyKYRN7mwr6bgJbY4lRBzwl862uQm8lLBxlKClDB3yMySicGp2UdLwRT65Hd1u f1pg== X-Received: by 10.14.1.130 with SMTP id 2mr48908170eed.15.1365428342264; Mon, 08 Apr 2013 06:39:02 -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 f47sm32097219eep.13.2013.04.08.06.38.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 06:39:01 -0700 (PDT) Message-ID: <5162C86F.7040104@gmail.com> Date: Mon, 08 Apr 2013 15:38:55 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130408153855829 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:39:04 -0000 On 08.04.2013 14:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski > wrote: >> Today is the last day of this WGLC and the response has been >> abysmal for now. > > This is a bit frustrating—I think the problem that the prefix pool > option is addressing is a real problem, but it's so leading edge > that I don't think a lot of people have really thought about it. I > think it's a problem that we ought to solve, but if nobody is willing > to think about it, it's questionable that it's a good idea for the > working group to push the solution. > > How many people have actually reviewed the draft at this point and > understand the problem it's trying to solve? I did review it (I think twice - first when it was individual draft and later when it was adopted). I've posted couple comments on it some time ago, but my understanding is that there are 2 outstanding issues that cannot be easily solved: Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process. So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain". I think the biggest issue here is a lack of support. There's really nobody saying "yes, I support this work moving forward". Gang sent some comments, but he didn't state his support clearly. Even you are saying that this is important problem and it needs to be solved, but you didn't say "this is the solution I want" or "I support this work". On a related note, there's a question in doc write-up: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As a chair, I wouldn't know how to answer it if we decided to somehow continue forward with this document. So far it seems there's no consensus, and chairs even can't say that there's a strong concurrence of a few individuals, because that "a few" would be just a subset of co-authors: Leaf and Ted. There are other smaller issues as well: security considerations is really empty, ipv6-prefix field length is not precisely defined, this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. I did not had enough time to thoroughly review this draft, so I haven't posted my review of -02. Some of the issues were reported earlier, but they are still not resolved. Tomek From Ted.Lemon@nominum.com Mon Apr 8 06:52:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46C921F9310 for ; Mon, 8 Apr 2013 06:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 KJJ-JtSywtzo for ; Mon, 8 Apr 2013 06:52:51 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 544B621F9452 for ; Mon, 8 Apr 2013 06:52:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUWLLs4h4ipRTvBEyCkDufUiwzTjkynqS@postini.com; Mon, 08 Apr 2013 06:52: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 EA6DC108391 for ; Mon, 8 Apr 2013 06:52:50 -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 E3995190061; Mon, 8 Apr 2013 06:52:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 06:52:50 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac4ozYfaibHYbpaWSZS5v8sktAaRTwLwlbAAAABEPwAAAgmxgAAAfGwA Date: Mon, 8 Apr 2013 13:52:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751383EC@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> In-Reply-To: <5162C86F.7040104@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:52:52 -0000 I think those are very good comments; perhaps we can work with the author t= o address them... :) From jyrki.soini@teliasonera.com Mon Apr 8 07:29:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0031321F93DC for ; Mon, 8 Apr 2013 07:29:38 -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 HhMnYtrCGuK3 for ; Mon, 8 Apr 2013 07:29:38 -0700 (PDT) Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by ietfa.amsl.com (Postfix) with ESMTP id 557EA21F93B1 for ; Mon, 8 Apr 2013 07:29:38 -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 E9965220A; Mon, 8 Apr 2013 17:29:35 +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 2B4AD1EE8C3; Mon, 8 Apr 2013 17:07:57 +0300 (EEST) Received: from [131.177.116.206] (ws906.secureuser.sonera.fi [131.177.116.206]) by smtp.dave.sonera.fi (Postfix) with ESMTP id AB0F45803A; Mon, 8 Apr 2013 17:29:35 +0300 (EEST) Message-ID: <5162D44F.6000305@teliasonera.com> Date: Mon, 08 Apr 2013 17:29:35 +0300 From: Jyrki Soini User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Ted Lemon , Tomek Mrugalski References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:29:39 -0000 On 8.4.2013 15:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski wrote: >> Today is the last day of this WGLC and the response has been abysmal for >> now. > > This is a bit frustrating—I think the problem that the prefix pool option is addressing is a real problem, but it's so leading edge that I don't think a lot of people have really thought about it. I think it's a problem that we ought to solve, but if nobody is willing to think about it, it's questionable that it's a good idea for the working group to push the solution. > > How many people have actually reviewed the draft at this point and understand the problem it's trying to solve? > > This mechanism is needed. I read the draft and agree with the approach. There is one issue, that could be clarified, IMHO: What is the relation between prefix-pool and PE router customer facing interface? Is there one-to-one mapping between prefix-pool and customer facing interface? Can the same prefix-pool be shared with multiple customer facing interfaces? In this case what happens if customer lease from the original CFI#1 is released, but other leases are still active. And further, if CFI#1 later receives a lease from another prefix-pool. Can the customer facing interface share multiple prefix-pools? Is many-to-many relation possible? -- Jyrki From leaf.yeh.sdo@gmail.com Mon Apr 8 07:35:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9A21F97D9; Mon, 8 Apr 2013 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AujwTgALxPQQ; Mon, 8 Apr 2013 07:35:23 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4246621F97D7; Mon, 8 Apr 2013 07:35:23 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id kp14so3235316pab.8 for ; Mon, 08 Apr 2013 07:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=qTab5rnx1VsUm9i7fa2TEzINOeSIuW4Qqs8C+ZxrEPQ=; b=MeT+idPtY3ZndsKfTy2tDyzoGijEg1hhPc3Cnto59bFJqJzj9/AFK2lLeSRTamu8gH 9JXauAS2nN+kkRSua7ZuhwkZF0CJze80SNC0OBu9zxvamRDOWYygThD5WAZhHYbeMkkO wE75FIjaVCNHt3IzJi7BASVrWdzYVrPijlm0yfLX9gAW/SFPaK2BmG9Jr+KYuRNAMKr1 K0GZBLxW0BL2rW7Hcl547Qhu1RZbcGzna0ZjzDUDPWBnY0wMTnRd3oLrHn/5GyG5LI5g AP853bvA9cf0mW3CxRF7X3hhS+hWzDxC1GI03iw558G1htVGtmfzXmD3bB2lJaDxKsJn WysQ== X-Received: by 10.66.219.136 with SMTP id po8mr24849398pac.53.1365431722591; Mon, 08 Apr 2013 07:35:22 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id to7sm40250501pab.0.2013.04.08.07.34.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 07:35:22 -0700 (PDT) From: "Leaf Yeh" To: "'Jouni Korhonen'" , References: In-Reply-To: Date: Mon, 8 Apr 2013 22:34:33 +0800 Message-ID: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01CE34A9.43392920" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac40KydsA3cjSiyLRsiJsmwVRvqQGAANtouw Content-Language: zh-cn Cc: 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 14:35:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01CE34A9.43392920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jouni - it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay. Does that sounds a question for the newly introduced attribute? Anyway, the server is supposed to know the meaning of the attributes from the relay before its response; if not, the server will silently ignore it. Right? Best Regards, Leaf From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Monday, April 08, 2013 3:32 PM To: Cc: dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Seems that I forgot to CC mailing lists. - Jouni Begin forwarded message: From: jouni korhonen Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Date: April 5, 2013 7:37:47 PM GMT+03:00 To: Tomek Mrugalski 5.4.2013 17.16 "Tomek Mrugalski" kirjoitti: > > On 05.04.2013 15:12, Ted Lemon wrote: > > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen > > wrote: > >> Blindly dropping an attribute might not work in all cases. For > >> example, in some cases the server might not then be able to provide > >> all information the relay needs.. > > > > Well, I did say "silently ignored," not "dropped," but yeah. If the > > server doesn't support that attribute, it's not going to have any > > effect anyway. It seems like silently ignoring it is better than > > dropping the whole message, although I suppose you could argue the > > opposite, since a misconfiguration of this sort is probably something > > the administrator wants to fix immediately, not discover by accident > > years later. > Anyway, dropping the whole message is definitely too radical here. We I was not suggesting dropping the message. I said "blindly dropping an attribute".. which is somewhat different. I am fine with a) but my point was that it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay. This needs to be taken into account when defining DHCP extensions relying on this I-D and the established registry. Jouni > have 3 options when server receives an unknown attribute: > a) ignore just the unknown attribute > b) ignore the whole radius option > c) ignore the whole message > > I think we have an agreement that a) is the way to go. At least that's > what I strongly recommend. > > Also, depending on server implementation, it is quite likely that the > server will parse unknown attributes and handle them in some generic > way, e.g. hex string. This is what some implementations do with unknown > DHCPv6 options and I imagine similar approach can be taken with RADIUS > attributes. Of course, such a behaviour is strictly implementation > specific, so there's no need to put anything about it in the spec. > So whether the attribute is "unknown" or not may be a bit blurry > definition sometimes. > > "Server MAY ignore received RADIUS attributes that it does not support." > seems like a reasonable text here. Some implementors will ignore unknown > attribute, some may produce a warning and some my try to handle it in a > generic way. > > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_000_00C1_01CE34A9.43392920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jouni - it is possible in future when new attributes get = added to registry server silently discarding attributes may lead to a = situation where the server fails to provide enough information back to = relay.

 

Does that sounds a question for the newly introduced attribute? =

Anyway, the server is supposed to know the meaning of the attributes = from the relay before its response; if not, the server will silently = ignore it. Right?

 

 

Best Regards,

Leaf

 

 

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Jouni Korhonen
Sent: Monday, April 08, 2013 3:32 = PM
To: <radext@ietf.org>
Cc: = dhcwg
Subject: Re: [dhcwg] [radext] = draft-ietf-dhc-dhcpv6-radius-opt-10

 

Seems that I forgot to CC mailing = lists.

 

- = Jouni

 

Begin forwarded message:



From: = jouni = korhonen <jouni.nospam@gmail.com>

Subject: = Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Date: = April 5, = 2013 7:37:47 PM GMT+03:00

To: = Tomek = Mrugalski <tomasz.mrugalski@gmail.com= >

 


5.4.2013 17.16 "Tomek Mrugalski" <tomasz.mrugalski@gmail.com= > kirjoitti:
>
> On 05.04.2013 15:12, Ted Lemon = wrote:
> > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <jouni.nospam@gmail.com>
= > > wrote:
> >> Blindly dropping an attribute might = not work in all cases. For
> >> example, in some cases the = server might not then be able to provide
> >> all = information the relay needs..
> >
> > Well, I did say = "silently ignored," not "dropped," but yeah.   = If the
> > server doesn't support that attribute, it's not = going to have any
> > effect anyway.   It seems like = silently ignoring it is better than
> > dropping the whole = message, although I suppose you could argue the
> > opposite, = since a misconfiguration of this sort is probably something
> > = the administrator wants to fix immediately, not discover by = accident
> > years later.
> Anyway, dropping the whole = message is definitely too radical here. We

I was not suggesting dropping the message. I said = "blindly dropping an attribute".. which is somewhat different. = I am fine with a) but my point was that it is possible in future when = new attributes get added to registry server silently discarding = attributes may lead to a situation where the server fails to provide = enough information back to relay. This needs to be taken into account = when defining DHCP extensions relying on this I-D and the established = registry.

Jouni

> have = 3 options when server receives an unknown attribute:
> a) ignore = just the unknown attribute
> b) ignore the whole radius = option
> c) ignore the whole message
>
> I think we = have an agreement that a) is the way to go. At least that's
> what = I strongly recommend.
>
> Also, depending on server = implementation, it is quite likely that the
> server will parse = unknown attributes and handle them in some generic
> way, e.g. hex = string. This is what some implementations do with unknown
> DHCPv6 = options and I imagine similar approach can be taken with RADIUS
> = attributes. Of course, such a behaviour is strictly = implementation
> specific, so there's no need to put anything = about it in the spec.
> So whether the attribute is = "unknown" or not may be a bit blurry
> definition = sometimes.
>
> "Server MAY ignore received RADIUS = attributes that it does not support."
> seems like a = reasonable text here. Some implementors will ignore unknown
> = attribute, some may produce a warning and some my try to handle it in = a
> generic way.
>
> Tomek
> = _______________________________________________
> dhcwg mailing = list
> dhcwg@ietf.org
> https://www.ietf.org= /mailman/listinfo/dhcwg

 

------=_NextPart_000_00C1_01CE34A9.43392920-- From internet-drafts@ietf.org Mon Apr 8 08:26:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358821F9818; Mon, 8 Apr 2013 08:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, 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 lHaeEsbGRpJf; Mon, 8 Apr 2013 08:26:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 060AE21F97FA; Mon, 8 Apr 2013 08:26: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: 4.43.p3 Message-ID: <20130408152601.17683.1420.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 08:26:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-container-opt-07.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, 08 Apr 2013 15:26: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 Group = of the IETF. Title : Container Option for Server Configuration Author(s) : Ralph Droms Reinaldo Penno Filename : draft-ietf-dhc-container-opt-07.txt Pages : 9 Date : 2013-04-08 Abstract: In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-container-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-container-opt-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-container-opt-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Mon Apr 8 08:42:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C021F9421; Mon, 8 Apr 2013 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.006, 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 4A06-DN487qa; Mon, 8 Apr 2013 08:42:00 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A183321F9415; Mon, 8 Apr 2013 08:42:00 -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 DSNKUWLlSN/vkFvJzAYM3JbzHv3BiKj1rOGg@postini.com; Mon, 08 Apr 2013 08:42:00 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 49CB3108394; Mon, 8 Apr 2013 08:42:00 -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 41C80190061; Mon, 8 Apr 2013 08:42:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 08:42:00 -0700 From: Ted Lemon To: Leaf Yeh Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14A= Date: Mon, 8 Apr 2013 15:41:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> In-Reply-To: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_" MIME-Version: 1.0 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 15:42:01 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 8, 2013, at 10:34 AM, Leaf Yeh > wrote: Jouni - it is possible in future when new attributes get added to registry = server silently discarding attributes may lead to a situation where the ser= ver fails to provide enough information back to relay. Also, having the server reflect the option back is easy; having it make cha= nges to the option is actually a protocol update, and probably not a good i= dea. --_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <0A376C5C2B565942B911568E7B64E6C9@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 8, 2013, at 10:34 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:
Jouni - it is possible in future when new attributes get added to registry serve= r silently discarding attributes may lead to a situation where the server f= ails to provide enough information back to relay.

Also, having the server reflect the option back is easy; having it mak= e changes to the option is actually a protocol update, and probably not a g= ood idea.

--_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_-- From leaf.yeh.sdo@gmail.com Mon Apr 8 09:12:38 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2890621F97D7 for ; Mon, 8 Apr 2013 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=-2.946, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 IeVfrsHulwZz for ; Mon, 8 Apr 2013 09:12:37 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 621CA21F97D5 for ; Mon, 8 Apr 2013 09:12:37 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so7216611ieb.34 for ; Mon, 08 Apr 2013 09:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=IQ3Ta6yoNsSYVKpfJjiSBAx2PrhOfA1leBpC67JZ4Gk=; b=k6ECcDZifitdK8HocB5+SJFWMzT1zoMufs7WWYq1VrjDfaI/sA8/pvu0gicZ1FWeyz VGodZScAOx1uiYj2t3efwaoQcnowwcoEHlNWpW1Z7tawgBifBEWsxLpx/zfQNqn9AEsV rgSDaqDII6kfSdYAoSeq/ACHdPrrJVt8ao2HSkI6ZSjlvyXIKaJZ/apSSizVukZMAe7k gzw9N6pVdcReFuWCEtxzNDJEnlQmSWYEvZ0ED6kUWadjjx/TKoooDaEKtf67StXx2RTz wa+2VnhaY802jzT93I2S0IjDMuw1v6fm0qEym5lzwAOhFSt6Ggm8tx0WzPUP4pfkW75O pdmQ== X-Received: by 10.50.20.69 with SMTP id l5mr7635435ige.106.1365437556725; Mon, 08 Apr 2013 09:12:36 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id in10sm21919737igc.1.2013.04.08.09.12.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 09:12:36 -0700 (PDT) From: "Leaf Yeh" To: "'Jyrki Soini'" , "'Ted Lemon'" , "'Tomek Mrugalski'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162D44F.6000305@teliasonera.com> In-Reply-To: <5162D44F.6000305@teliasonera.com> Date: Tue, 9 Apr 2013 00:12:28 +0800 Message-ID: <5162ec74.aac4320a.5fb9.fffff58f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac40ZYIjkhbb1+QDRMudOPkA7hhFtQAAQjlQ Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:12:38 -0000 Hi Jyrki, Thanks for your review & comments. Jyrki - There is one issue, that could be clarified, IMHO: What is the = relation between prefix-pool and PE router customer facing interface? Is = there one-to-one mapping between prefix-pool and customer facing = interface? In Fig.2 (or use case 2) of the draft (OPTION_PREFIX_POOL), the prefix = pool is associated with the CFI-Customer facing interface on PE. The = server is responsible to keep the binding (or mapping ) between the = prefix pool & the associated CFI of the PE.=20 Jyrki - Can the same prefix-pool be shared with multiple customer facing = interfaces? In this case what happens if customer lease from the = original CFI#1 is released, but other leases are still active. In Fig.1 (or use case 1) of the draft, the prefix pool is associated = with the whole PE, sharing with all CFIs. The server is responsible to = keep the binding (or mapping ) between the prefix pool & the associated = PE. Jyrki - And further, if CFI#1 later receives a lease from another = prefix-pool. Can the customer facing interface share multiple = prefix-pools? =20 The draft supports the case when multiple prefix pools are associated = with the same CFI. Jyrki - Is many-to-many relation possible? Still not quite sure whether it is necessary in the real address = planning & deployment? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Jyrki Soini Sent: Monday, April 08, 2013 10:30 PM To: Ted Lemon; Tomek Mrugalski Cc: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - = Respond by April 8, 2013 On 8.4.2013 15:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski = wrote: >> Today is the last day of this WGLC and the response has been abysmal=20 >> for now. >=20 > This is a bit frustrating=E2=80=94I think the problem that the prefix = pool option is addressing is a real problem, but it's so leading edge = that I don't think a lot of people have really thought about it. I = think it's a problem that we ought to solve, but if nobody is willing to = think about it, it's questionable that it's a good idea for the working = group to push the solution. >=20 > How many people have actually reviewed the draft at this point and = understand the problem it's trying to solve? >=20 >=20 This mechanism is needed. I read the draft and agree with the approach. There is one issue, that could be clarified, IMHO: What is the relation = between prefix-pool and PE router customer facing interface? Is there one-to-one mapping between prefix-pool and customer facing = interface? Can the same prefix-pool be shared with multiple customer facing = interfaces? In this case what happens if customer lease from the = original CFI#1 is released, but other leases are still active. And further, if CFI#1 later receives a lease from another prefix-pool. Can the customer facing interface share multiple prefix-pools? Is many-to-many relation possible? -- Jyrki _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 8 09:25:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9121F9415; Mon, 8 Apr 2013 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSkG9IYVZlwU; Mon, 8 Apr 2013 09:25:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2421F9410; Mon, 8 Apr 2013 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10677; q=dns/txt; s=iport; t=1365438306; x=1366647906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rSbWy5PtlFkWtIXPnP0IpjxpUlWka2brqqj7J6cFBpc=; b=OUfAP3BThx1konH0gy7bGxdGntnWio15F2EqP1nK4QdzFkPhEz7NHHtM nitCXyANZKu4kamGUrVhTblrqH1+5dpBkZt2oSWqSMy/xC9H8eJrvVLuB 8UjKwjrq8FBNb/y3SEq2lt2mxc6vGCpaxVWeIV5hi20QMxY0YZZ1HScqk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAIruYlGtJXG8/2dsb2JhbABRgkJENsEsgQoWdIIfAQEBAwEtTAULAgEIEQQBAQsdByERFAkIAgQBDQUIh3oDCQazMQ2JXYkLg0WCIjEGAYJgYQOVE41UhRuDC4Io X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="scan'208,217";a="196286228" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 08 Apr 2013 16:25:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r38GP5TL025192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 16:25:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 11:25:05 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Leaf Yeh Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wA== Date: Mon, 8 Apr 2013 16:25:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.121] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "" , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 16:25:07 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (This is with chair hat off! I have to remember to indicate that.) > having the server reflect the option back is easy The ERO option can be specified to cause the server to send back the option= to the relay. I don't think we want to server to "change" the data in the = option. I wonder whether Jouni's concern is that the server may not send the client= the correct response? But in that case you need to assure your server is u= pdated accordingly (to use the new Radius attribute) and I don't see that t= his is really a concern for this document? We can't assume servers would know how to do something for something that i= s not yet defined. The "old" server ignoring the attribute in the option is= the correct action until it is updated. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, April 08, 2013 11:42 AM To: Leaf Yeh Cc: ; dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 On Apr 8, 2013, at 10:34 AM, Leaf Yeh > wrote: Jouni - it is possible in future when new attributes get added to registry = server silently discarding attributes may lead to a situation where the ser= ver fails to provide enough information back to relay. Also, having the server reflect the option back is easy; having it make cha= nges to the option is actually a protocol update, and probably not a good i= dea. --_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(This is with chair hat o= ff! I have to remember to indicate that.)

 <= /p>

> having the se= rver reflect the option back is easy<= /span>

 <= /p>

The ERO option can be spe= cified to cause the server to send back the option to the relay. I don̵= 7;t think we want to server to “change” the data in the option.=

 <= /p>

I wonder whether Jouni= 217;s concern is that the server may not send the client the correct respon= se? But in that case you need to assure your server is updated accordingly (to use the new Radius attribute) and I don’t see that t= his is really a concern for this document?

 <= /p>

We can’t assume ser= vers would know how to do something for something that is not yet defined. = The “old” server ignoring the attribute in the option is the co= rrect action until it is updated.

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Monday, April 08, 2013 11:42 AM
To: Leaf Yeh
Cc: <radext@ietf.org>; dhcwg
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

 

On Apr 8, 2013, at 10:34 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:<= /o:p>

Jouni - it is possible in future when new attributes= get added to registry server silently discarding attributes may lead to a = situation where the server fails to provide enough information back to rela= y.

 

Also, having the server reflect the option back is e= asy; having it make changes to the option is actually a protocol update, an= d probably not a good idea.

 

--_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_-- From volz@cisco.com Mon Apr 8 09:40:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B851921F93A3 for ; Mon, 8 Apr 2013 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SnYyMI1n-Va for ; Mon, 8 Apr 2013 09:40:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A94F621F9397 for ; Mon, 8 Apr 2013 09:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5417; q=dns/txt; s=iport; t=1365439242; x=1366648842; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xPg/NEWoXPuDnNHKrtzOE2oxjHcMMrQqKjnDY1VCOf0=; b=QJqmGJfPEc1Vtmo/lg915Yw82YANaf4ty6+oOeHoRJ0kaJuxRd1jWWdV S7gCM2j7ZuhYytLzY93fExJAnVDQ+A3rqdhn+HeFztwPl4XZzTZg+iS6N RkSav/apC5GYGnu9klu3qkWNPWbTxg/TvVA8XEuEJJAZ3fyBAQkgCZlG+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFALfyYlGtJXG9/2dsb2JhbABRgwY2wSyBChZ0gh8BAQEEAQEBNzQXBAIBCBEEAQEBChQJByEGCxQJCAEBBBMIE4dnAw8MszMNiVkEjFCCIiYSBoJaYQOVE41UhRuBVYE2gig X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="scan'208";a="196352835" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 08 Apr 2013 16:40:37 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r38GebZM019821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Apr 2013 16:40:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 11:40:37 -0500 From: "Bernie Volz (volz)" To: "" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac4ozYfaibHYbpaWSZS5v8sktAaRTwLsZM4AAABEPwAAAgmwgAAEpzoQ Date: Mon, 8 Apr 2013 16:40:36 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184EBB40@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> In-Reply-To: <5162C86F.7040104@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:40:43 -0000 (WG hat co-chair off.) This document seems to be about avoiding having to manually configure the a= ggregate prefix at the "Provider Edge Router"? My issue with this is that there is still other configuration that needs to= be configured - such as the DHCPv6 server's address, the link-address or o= ther "identifying" information to know which prefix(es) are in play, etc. Yes, there might be deployments where using multicast addressing (as per RF= C 3315) and having the DHCPv6 server allocate a prefix for the first time i= t detects the provider edge router, could be done - is this likely? So, while this document provides for some more auto-configuration, is it re= ally worth it?=20 Also, I have concerns about what might happen if the prefix-pool is ::/0 or= similarly misconfigured. I suppose this is no worse than the security issu= es with PD in general but it should be mentioned in the security considerat= ions. There should also be some requirements that the pool contain the dele= gated prefix (though that of course doesn't solve the ::/0 issue since ever= ything is contained in that). In the end, I am on the fence with the need for this as I see it as only a = small part of the router auto-configuration issue. If there were people that are eager to implement it (or might already have = in some form), I'd could be swayed. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Monday, April 08, 2013 9:39 AM To: Ted Lemon Cc: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Resp= ond by April 8, 2013 On 08.04.2013 14:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski=20 > wrote: >> Today is the last day of this WGLC and the response has been abysmal=20 >> for now. >=20 > This is a bit frustrating-I think the problem that the prefix pool=20 > option is addressing is a real problem, but it's so leading edge > that I don't think a lot of people have really thought about it. I > think it's a problem that we ought to solve, but if nobody is willing=20 > to think about it, it's questionable that it's a good idea for the=20 > working group to push the solution. >=20 > How many people have actually reviewed the draft at this point and=20 > understand the problem it's trying to solve? I did review it (I think twice - first when it was individual draft and lat= er when it was adopted). I've posted couple comments on it some time ago, b= ut my understanding is that there are 2 outstanding issues that cannot be e= asily solved: Issue 1) this draft allows really stupid things, for example: you can relea= se (or stop aggregating) prefix-pool when responding to REQUEST and you can= allocate (or rather aggregate) when responding to RELEASE Issue 2) Take this scenario: the PD for your last client connected through = the relay expires (rather than is being released). Your relay will get stuc= k with outdated info, because there is no other DHCP traffic that server ca= n piggyback on. You could argue that leasequery can help here, but how ofte= n would the relay do the query? This may introduce non-trivial amount of ex= tra traffic for the server to process. So to answer your question: I *think* I understand the problem, I just don'= t have enough experience in managing ISP networks to say whether this is th= e right solution to the problem or not. That's why I haven't expressed my s= upport here. It is not that I'm opposing. I will count myself as "abstain". I think the biggest issue here is a lack of support. There's really nobody = saying "yes, I support this work moving forward". Gang sent some comments, = but he didn't state his support clearly. Even you are saying that this is i= mportant problem and it needs to be solved, but you didn't say "this is the= solution I want" or "I support this work". On a related note, there's a question in doc write-up: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As a chair, I wouldn't know how to answer it if we decided to somehow conti= nue forward with this document. So far it seems there's no consensus, and c= hairs even can't say that there's a strong concurrence of a few individuals= , because that "a few" would be just a subset of co-authors: Leaf and Ted. There are other smaller issues as well: security considerations is really e= mpty, ipv6-prefix field length is not precisely defined, this draft talks a= bout leasequery, but does not clearly define requestor behavior (I know tha= t requestor in most cases is part of a relay, but from protocol perspective= these are separate entities), this draft repeats normative language from R= FC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it = is not idnits clean etc. I did not had enough time to thoroughly review this draft, so I haven't pos= ted my review of -02. Some of the issues were reported earlier, but they ar= e still not resolved. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Mon Apr 8 09:52:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5DE21F9298 for ; Mon, 8 Apr 2013 09:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.788, 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 sx2er-vgPI-w for ; Mon, 8 Apr 2013 09:52:50 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2821F84E3 for ; Mon, 8 Apr 2013 09:52:49 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c4so2417498eek.10 for ; Mon, 08 Apr 2013 09:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=yeIn9atIbG3QreBP6qhdj0KG4XfrjJ41DrlMysIP8E4=; b=wxX7gZbvqhTvAGsmAM1/gJRxavP3hit08fUROTRmoul9mSy3gikQcslIiV1AyKBlOg uSn9AthpJKsii1TQAuBrhT9MLAEOZRByvgs+x3v8eeXvXA+ixpCeVzMtnb9/pOd31vnH NCca5vQ5O5mYnJfDYKweBgkXUhUbJXffxJDjUp0TJSWw81J6nW2ai6ipgTI6bX2+OAu9 ik3v2XrIQ3O0ZJL3eABk1KEZLVknpf6ojTgAs+JYg/Db8Fs2gEhAsLVZKI3O1+bghdyh /vnMoq8aDG0fRiu36Ntf+e2BBGM9ECzT0aKBe4mu1olN/AT3YMe/OBCws7NnT2l2O/u3 Orpw== X-Received: by 10.15.102.3 with SMTP id bq3mr24266369eeb.42.1365439968543; Mon, 08 Apr 2013 09:52: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 cd3sm23326954eeb.6.2013.04.08.09.52.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 09:52:47 -0700 (PDT) Message-ID: <5162F5DB.7010404@gmail.com> Date: Mon, 08 Apr 2013 18:52:43 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> X-TagToolbar-Keys: D20130408185243755 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:52:51 -0000 On 03.04.2013 20:04, Bernie Volz (volz) wrote: > While I think it is appropriate for the WG to adopt this document, I do have comments on the draft itself. This is a small, but important draft. By clarifying that relays must forward unknown messages it provides forward compatibility with any future extensions that define new message types. We know that there's one around the corner already, but there may be more ahead. It is very useful. I do support adoption of this draft. This is definitely something DHC WG should work on. Fortunately, there's not much work left to be done. Minor comment: I would add in section 3.2 "regardless of the message type in Relay Message option". Tomek From Ted.Lemon@nominum.com Mon Apr 8 10:00:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B627321F93D6 for ; Mon, 8 Apr 2013 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 m5-I6ewyrtux for ; Mon, 8 Apr 2013 10:00:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7EF21F93C4 for ; Mon, 8 Apr 2013 10:00:10 -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 DSNKUWL3mrHpdHGViyaUhbdIyDUFJxy4Yxkw@postini.com; Mon, 08 Apr 2013 10:00: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 ED9A5108390 for ; Mon, 8 Apr 2013 10:00:09 -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 E3AC5190061; Mon, 8 Apr 2013 10:00:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 10:00:10 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac4ozYfaibHYbpaWSZS5v8sktAaRTwLwlbAAAABEPwAAAgmxgAAGWGAAAACuyoA= Date: Mon, 8 Apr 2013 17:00:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775138B1C@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <489D13FBFA9B3E41812EA89F188F018E184EBB40@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EBB40@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:00:17 -0000 On Apr 8, 2013, at 12:40 PM, "Bernie Volz (volz)" wrote: > My issue with this is that there is still other configuration that needs = to be configured - such as the DHCPv6 server's address, the link-address or= other "identifying" information to know which prefix(es) are in play, etc. Okay, but these all seem like things that are much less dynamic than prefix= es. From leaf.yeh.sdo@gmail.com Mon Apr 8 10:31:45 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD221F95ED; Mon, 8 Apr 2013 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=-2.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 Y41dR3688Uq2; Mon, 8 Apr 2013 10:31:45 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4321F9577; Mon, 8 Apr 2013 10:31:45 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so7324169iec.18 for ; Mon, 08 Apr 2013 10:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=2ERwQXfvVLpbTc1jqFGrOSZnjeuA5epX2M1gM7I384E=; b=0bSZry82BcnegdbFkWHw723nPj2CtF47Nn7qH9aSRax1ATlC0jC5Pftgp7NZj0vu9e UnZWmXSk1wQ5yZRd0Keg88dWIOM38SE10A0YO6DrWo3SG1DDa1f8OdLr7wOMkcFt5qFc 6oPLTFIZFKNKBnha13NJmgMcBp6XbnbkW1jgG6WmtEXrXyb6SQupuv0Dgf/JTdIoiw33 f+G5+qd9YdEI5DDRmuAM0sNS1fdc3Evcyzmu48x3XJNJbmiRymoNGY91X0LiYQkyppFU MFzkW4vHj7E7doy5RHF6dk6EJ/pKTE5GYRJzndzFtkyqJaF1s+q8PV1qzfXilR+kQ+0L WVqA== X-Received: by 10.42.247.8 with SMTP id ma8mr12570815icb.1.1365442304252; Mon, 08 Apr 2013 10:31:44 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id ip2sm18310754igc.5.2013.04.08.10.31.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 10:31:43 -0700 (PDT) From: "Leaf Yeh" To: "'Alan DeKok'" , "'Ted Lemon'" References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> <515EDCC7.5010708@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> <515EDF8C.90104@deployingradius.com> In-Reply-To: <515EDF8C.90104@deployingradius.com> Date: Tue, 9 Apr 2013 01:31:36 +0800 Message-ID: <5162feff.e2c4320a.4c2e.4d83@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4yCeWxcMGiRw5nTrO1UXPWF7CTRgAEd9hQ Content-Language: zh-cn Cc: 'dhcwg' , radext@ietf.org Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 17:31:45 -0000 Tomek - "Server MAY ignore received RADIUS attributes that it does not support." The draft (ver.-11) will have no further update on this point. OK? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Friday, April 05, 2013 10:28 PM To: Ted Lemon Cc: dhcwg; Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Ted Lemon wrote: > Generally speaking, this sort of language is a recipe for attack. I think the draft should just say that the administrator should be able to update the list of acceptable options. That's probably best. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Mon Apr 8 10:31:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCAE21F97B9; Mon, 8 Apr 2013 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[AWL=-2.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 Ec4c2GRRfa89; Mon, 8 Apr 2013 10:31:48 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 97F5221F97B7; Mon, 8 Apr 2013 10:31:48 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id w33so5309583iag.8 for ; Mon, 08 Apr 2013 10:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=dPbvYLNyJwbN1QF1vmjIg5lPFtDipl+KUOKfqs1f0EU=; b=ujjbSLLVvChTHfXCWrCQ7jorEqZKVO9DMO9elfvB9KTlen2EfZG4GubUge9tTPQ5OE Mb4kAqi1EuioJcH+3qdqIIuoMs462PeuwF0Ku1GatzuJhM6IvSVyuFK/Mwfcprj14Cdl tNoc/I2ls2KkhtUIqYFSwiIQfl3ig6IXF9zJNVCc9UeJbNMbonG7HQVsweBl38c5dfB1 FcKl46H2czmxdytcg7USjG2zj/CYfF26G/JY982FZ9izG9QQh4/VWvDDhf1c3OcZs1Qf TvdQlCdtTgIW2yzarg/Q9uLS4YMAEfwCvFCLYlOSS12j/SeCPkofWg2ABmhpP7hFM+fh TOfw== X-Received: by 10.50.212.74 with SMTP id ni10mr7916340igc.60.1365442307934; Mon, 08 Apr 2013 10:31:47 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id ip2sm18310754igc.5.2013.04.08.10.31.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 10:31:47 -0700 (PDT) From: "Leaf Yeh" To: "'Jouni Korhonen'" , "'Ted Lemon'" References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> In-Reply-To: Date: Tue, 9 Apr 2013 01:31:36 +0800 Message-ID: <5162ff03.e2c4320a.4c2e.4d89@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4x/DTwlyIftvbWQ5+H5ZTlKErHfQAHyYnw Content-Language: zh-cn Cc: radext@ietf.org, 'Alan DeKok' , 'dhcwg' Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 17:31:49 -0000 Jouni - If that is a concern one can always change the "can only" to "MUST". The draft (ver.-11) will take this point. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, April 05, 2013 8:51 PM To: Ted Lemon Cc: ; dhcwg; Alan DeKok Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 On Apr 5, 2013, at 2:42 PM, Ted Lemon wrote: > On Apr 5, 2013, at 3:19 AM, Jouni Korhonen wrote: >> The option-data of OPTION_RADIUS is a list of one or more RADIUS >> attributes received in the Access-Accept message from the RADIUS >> server. The OPTION_RADIUS can only contain RADIUS attributes listed >> in the IANA Registry of 'RADIUS attributes permitted in >> DHCPv6 RADIUS option'. > > So you took out the normative language, right? Was that intentional? That was intentional. If that is a concern one can always change the "can only" to "MUST". That works too, since the previous sentence already points out that the option contains one or more attributes, not all. >> The next question I have is what happens when a relay includes an >> attribute that the server does not understand or is not listed in the >> registry? There is no versioning thus it is possible that relay and >> server have a different understanding what the IANA registry is. Now >> the text in Section 6 only addresses the case where the server does not understand the DHCP option. > > Good question. I think the right answer is that that RADIUS attribute is silently ignored, because, as you say, the server might not be up to date. Blindly dropping an attribute might not work in all cases. For example, in some cases the server might not then be able to provide all information the relay needs.. That is more of a DHCP specification issue but what I would like to see in this I-D is some text pointing out that the server and the relay may have a different idea of the registry and the protocol design need to take that into account. - Jouni > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Mon Apr 8 10:31:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273D021F95ED for ; Mon, 8 Apr 2013 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[AWL=-1.841, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 WIOM1aACeD4q for ; Mon, 8 Apr 2013 10:31:53 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2B21F97D8 for ; Mon, 8 Apr 2013 10:31:53 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id x24so5434976iak.38 for ; Mon, 08 Apr 2013 10:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=LLq+mCoEWDlZeJpoaog5SBOuiGJjqtym28b+Sp2TdGQ=; b=HKpb7oZblVBo3Lz7sdmYxfjwLN1QfDIWVOCde5BRla/hF3ri9j5bxsm2wj/dvBRJ4Z 69dMIG+yrbsERH+IsNFPYZO2F4wGo42JI5MkZqvrQVLZmsq4QJL64/B4RHsd93CwYYNO ucI93/boH6i4kgP+bfLHuflCgEXHg9fH4Lply9a/facHnU58Ly29PE70Qmhv55burDQW CVluW3uKhpbHrgRuWh4Nz3KwlFylQVUe4sXmaV5Deyx2dnFLgqEtdHxDo+bPt/ywktoP hirqz5WkjNZqpP5yhrcD9D573QyF2OTS8U3ydMcPqYpAsXhWL4Ngvfvv+UNXuGKZN//U KHGw== X-Received: by 10.50.237.71 with SMTP id va7mr7659851igc.88.1365442310917; Mon, 08 Apr 2013 10:31:50 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id ip2sm18310754igc.5.2013.04.08.10.31.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 10:31:50 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" , "'Ted Lemon'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> In-Reply-To: <5162C86F.7040104@gmail.com> Date: Tue, 9 Apr 2013 01:31:36 +0800 Message-ID: <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac40XnXnDVPmpx5gRjaCatWZiCQi/QAFaPQA Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:31:54 -0000 Tomek - Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE Clarification - The key (or permit) of the above mechanism (or behavior) is that OPTION_PREFIX_POOL try to support the 'real-time' setting (or aggregation policy) change by the administrator. Or do you want to simplify this mechanism? Tomek - Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process. Clarification - The draft provide the mechanism that the relay can 'automatically withdraw the aggregation route' per its own table for tracking the status of the prefix pools if the PE needs the immediate 'sync' on those status. The PE router acting as the relay agent MAY set up a table for the lease or status of the prefix pools on it according to the leases of the delegated customer prefixes within the prefix pools. The lease of the prefix pool SHOULD dynamically set to be the maximum lease of the delegated customer prefix within it. If there is no route entry directing to the customer network within the aggregation route associated with the prefix pool or the lease of prefix pool runs out, the PE router acting as the relay agent SHOULD automatically withdraw the aggregation route. Or do you want to simplify this mechanism? Tomek - So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain". Let's stimulate more discussions on it. Tomek - There are other smaller issues as well: security considerations is really empty, Any more detailed review comments or suggested text on it? Tomek - ipv6-prefix field length is not precisely defined, Not quite sure about the issue? pfx-pool-len: Length for the prefix pool in Bits ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero. Tomek - this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), Do you want a separate section on the 'requestor behavior'? Tomek - this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. Not quite sure about the issue? Sounds not difficult to fix it? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Monday, April 08, 2013 9:39 PM To: Ted Lemon Cc: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 On 08.04.2013 14:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski > wrote: >> Today is the last day of this WGLC and the response has been abysmal >> for now. > > This is a bit frustrating-I think the problem that the prefix pool > option is addressing is a real problem, but it's so leading edge > that I don't think a lot of people have really thought about it. I > think it's a problem that we ought to solve, but if nobody is willing > to think about it, it's questionable that it's a good idea for the > working group to push the solution. > > How many people have actually reviewed the draft at this point and > understand the problem it's trying to solve? I did review it (I think twice - first when it was individual draft and later when it was adopted). I've posted couple comments on it some time ago, but my understanding is that there are 2 outstanding issues that cannot be easily solved: Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process. So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain". I think the biggest issue here is a lack of support. There's really nobody saying "yes, I support this work moving forward". Gang sent some comments, but he didn't state his support clearly. Even you are saying that this is important problem and it needs to be solved, but you didn't say "this is the solution I want" or "I support this work". On a related note, there's a question in doc write-up: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As a chair, I wouldn't know how to answer it if we decided to somehow continue forward with this document. So far it seems there's no consensus, and chairs even can't say that there's a strong concurrence of a few individuals, because that "a few" would be just a subset of co-authors: Leaf and Ted. There are other smaller issues as well: security considerations is really empty, ipv6-prefix field length is not precisely defined, this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. I did not had enough time to thoroughly review this draft, so I haven't posted my review of -02. Some of the issues were reported earlier, but they are still not resolved. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Mon Apr 8 11:02:18 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3221F8FAA for ; Mon, 8 Apr 2013 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[AWL=-1.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 tpFBSdPU2WrN for ; Mon, 8 Apr 2013 11:02:18 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id CF71E21F8F31 for ; Mon, 8 Apr 2013 11:02:17 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id a11so7224851iee.39 for ; Mon, 08 Apr 2013 11:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=b2o9+HJDRq/ENzujqJjRF20jUQ3zBorebyY098pY9DE=; b=GWg5s5S7aCAr61zPdHoHFaZaDL0TpNWG2HZ88XVoa4If89+GyVDzqeI+wmklQhipuZ N9pw1wdO/oQymeza6PZXjtmEqKTLbJW2Ho7DK3Yfk/9JtF+OUOcwuTUoTN5Gl6JkQxb5 JendruhZFaiBgjlrS3unY5XsWTbvL5xFf4+DYsGAkMRjLHCnL/PqURA7dCWafcBzcvyx AxYiSwUBtCWZ46Sqh70CyohBe51N3PdKGLqOtfl7peV6I0/1chw/9tcF4SJIBRujDAbl RTZoQNWsabPIq+zS5tCOaF3EjZRcK+ha8YTkNaBw6xEvnChw6vCMceb8F5GpkpTywO/r HDxQ== X-Received: by 10.42.136.67 with SMTP id s3mr12888014ict.31.1365444131293; Mon, 08 Apr 2013 11:02:11 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id px9sm22365939igc.0.2013.04.08.11.02.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 11:02:10 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <489D13FBFA9B3E41812EA89F188F018E184EBB40@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EBB40@xmb-rcd-x04.cisco.com> Date: Tue, 9 Apr 2013 02:01:53 +0800 Message-ID: <51630622.a9dc320a.4108.0f0f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4ozYfaibHYbpaWSZS5v8sktAaRTwLsZM4AAABEPwAAAgmwgAAEpzoQAAbMSfA= Content-Language: zh-cn Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:02:18 -0000 Thanks for the co-chair's review again. BV>My issue with this is that there is still other configuration that needs to be configured - such as the DHCPv6 server's address, the link-address or other "identifying" information to know which prefix(es) are in play, etc. DHCPv6 server's address always sounds the same ones in the same administrative domain. Link-address of relay sounds not always necessary in the un-numbered access network. Identifying" information sounds Interface ID in this draft, which is associated with the device. Right? BV>Also, I have concerns about what might happen if the prefix-pool is ::/0 or similarly misconfigured. I suppose this is no worse than the security issues with PD in general but it should be mentioned in the security considerations. I guess the automatic mechanism sounds a little safer than the manual configuration. :-) Any suggested text on the 'security consideration'? BV>There should also be some requirements that the pool contain the delegated prefix (though that of course doesn't solve the ::/0 issue since everything is contained in that). Note that these prefix pools SHOULD not overlay, and the delegated customer prefix is only from one prefix pool. Text enough? BV>If there were people that are eager to implement it (or might already have in some form), I'd could be swayed. I am eager to wait for your boat swayed. :-) Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, April 09, 2013 12:41 AM To: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 (WG hat co-chair off.) This document seems to be about avoiding having to manually configure the aggregate prefix at the "Provider Edge Router"? My issue with this is that there is still other configuration that needs to be configured - such as the DHCPv6 server's address, the link-address or other "identifying" information to know which prefix(es) are in play, etc. Yes, there might be deployments where using multicast addressing (as per RFC 3315) and having the DHCPv6 server allocate a prefix for the first time it detects the provider edge router, could be done - is this likely? So, while this document provides for some more auto-configuration, is it really worth it? Also, I have concerns about what might happen if the prefix-pool is ::/0 or similarly misconfigured. I suppose this is no worse than the security issues with PD in general but it should be mentioned in the security considerations. There should also be some requirements that the pool contain the delegated prefix (though that of course doesn't solve the ::/0 issue since everything is contained in that). In the end, I am on the fence with the need for this as I see it as only a small part of the router auto-configuration issue. If there were people that are eager to implement it (or might already have in some form), I'd could be swayed. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Monday, April 08, 2013 9:39 AM To: Ted Lemon Cc: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 On 08.04.2013 14:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski > wrote: >> Today is the last day of this WGLC and the response has been abysmal >> for now. > > This is a bit frustrating-I think the problem that the prefix pool > option is addressing is a real problem, but it's so leading edge > that I don't think a lot of people have really thought about it. I > think it's a problem that we ought to solve, but if nobody is willing > to think about it, it's questionable that it's a good idea for the > working group to push the solution. > > How many people have actually reviewed the draft at this point and > understand the problem it's trying to solve? I did review it (I think twice - first when it was individual draft and later when it was adopted). I've posted couple comments on it some time ago, but my understanding is that there are 2 outstanding issues that cannot be easily solved: Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process. So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain". I think the biggest issue here is a lack of support. There's really nobody saying "yes, I support this work moving forward". Gang sent some comments, but he didn't state his support clearly. Even you are saying that this is important problem and it needs to be solved, but you didn't say "this is the solution I want" or "I support this work". On a related note, there's a question in doc write-up: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As a chair, I wouldn't know how to answer it if we decided to somehow continue forward with this document. So far it seems there's no consensus, and chairs even can't say that there's a strong concurrence of a few individuals, because that "a few" would be just a subset of co-authors: Leaf and Ted. There are other smaller issues as well: security considerations is really empty, ipv6-prefix field length is not precisely defined, this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. I did not had enough time to thoroughly review this draft, so I haven't posted my review of -02. Some of the issues were reported earlier, but they are still not resolved. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ietf-ipr@ietf.org Mon Apr 8 11:42:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8621F95DA; Mon, 8 Apr 2013 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.235, 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 OMPHAou9jZ6v; Mon, 8 Apr 2013 11:42:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDE21F94A9; Mon, 8 Apr 2013 11:42:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: leaf.yeh.sdo@gmail.com, mohamed.boucadair@orange.com X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408184203.30405.26272.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 11:42:03 -0700 Cc: brian@innovationslab.net, volz@cisco.com, ted.lemon@nominum.com, dhcwg@ietf.org, ipr-announce@ietf.org Subject: [dhcwg] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 18:42:04 -0000 Dear leaf.yeh.sdo@gmail.com, Mohamed Boucadair: An IPR disclosure that pertains to your Internet-Draft entitled "RADIUS Op= tion for DHCPv6 Relay Agent" (draft-ietf-dhc-dhcpv6-radius-opt) was submitted to= the IETF Secretariat on 2013-04-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2052/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-dh= c- dhcpv6-radius-opt-10.""); The IETF Secretariat From ietf-ipr@ietf.org Mon Apr 8 11:43:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0D121F9726; Mon, 8 Apr 2013 11:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.235, 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 bnBr0AJjj7su; Mon, 8 Apr 2013 11:43:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7821F94A4; Mon, 8 Apr 2013 11:43:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ted.lemon@nominum.com, mohamed.boucadair@orange.com, leaf.yeh.sdo@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408184302.7323.12778.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 11:43:02 -0700 Cc: brian@innovationslab.net, volz@cisco.com, ted.lemon@nominum.com, dhcwg@ietf.org, ipr-announce@ietf.org Subject: [dhcwg] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:43:03 -0000 Dear Ted Lemon, Mohamed Boucadair, leaf.yeh.sdo@gmail.com: An IPR disclosure that pertains to your Internet-Draft entitled "Prefix Po= ol Option for DHCPv6 Relay Agent on the Provider Edge Routers" (draft-ietf-dhc- dhcpv6-prefix-pool-opt) was submitted to the IETF Secretariat on 2013-04-08= and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/2051/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-dh= c- dhcpv6-prefix-pool-opt-02.""); The IETF Secretariat From volz@cisco.com Mon Apr 8 13:35:31 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2D21F9322 for ; Mon, 8 Apr 2013 13:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8tDEU5qFUVy for ; Mon, 8 Apr 2013 13:35:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4865921F931E for ; Mon, 8 Apr 2013 13:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9781; q=dns/txt; s=iport; t=1365453330; x=1366662930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BIyDwmRoT0fbB0M2CyZBnll0Z+AWJKXZVP2GYSJ5ED4=; b=iD4gEoBjQOfrpyjGEjqYfWYRWR1tLf+lMw1F+Ci2P9nZl/fMgwRd5DVV eZTGGbOvS4aEkpptoS+y8xLiuRLHRkbJHhikt2oO64BdoRuU1KqbTC2n8 Pktf7Ji+Ne8ln4ryz0sZcaNCj9w/WSOgmri+kOBcIQtBHr/ho5LteyxbY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAgpY1GtJXHB/2dsb2JhbABRgwY2wSuBCxZ0gh8BAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQchBgsUCQgBAQQBDQUIE4dnAw8Ms3oNiVkEjFCCIiYLBwaCWmEDlRONVIUbgVWBNoIo X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="scan'208";a="193391090" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 08 Apr 2013 20:35:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r38KZT3p017718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 20:35:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 15:35:29 -0500 From: "Bernie Volz (volz)" To: Leaf Yeh , "'Tomek Mrugalski'" , "'Ted Lemon'" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac40XnXnDVPmpx5gRjaCatWZiCQi/QAFaPQAAAi7VDA= Date: Mon, 8 Apr 2013 20:35:28 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184EC3C0@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> In-Reply-To: <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:35:31 -0000 pfx-pool-len: Length for the prefix pool in Bits ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero. The issue here is that if pfx-pool-len is 60, I can provide 0-16 octets of = ipv6-prefix (or depending on how you interpret 8-16 octets). draft-ietf-dhc-option-guidelines-10 has: option-length is set to 1 + length of the IPv6 prefix. prefix6-len is one octet long and specifies the length in bits of the IPv6 prefix. Typically allowed values are 0 to 128. ipv6-prefix field is a variable length field that specifies the IPv6 prefix. This field is padded with zeros up to the nearest octet boundary when prefix6-len is not divisible by 8. Probably still not the best. I think we want to have the ipv6-prefix field = to contain only octets. So, for a 60, we would want it to have= 8 octets, not more or less? This is something we should clear up (also in draft-ietf-dhc-option-guideli= nes). The processing might be to initialize 16-octet buffer to all 0's, copy the = ipv6-prefix octets (up to 16) into that buffer. The resulting value is the = prefix. This would work and even allow the ipv6-prefix to be LESS than the= prefix length when the bits are 0 (such as if 2001::/60 is sent, really on= ly the first 2 octets are needed). Or, do we want to be more explicit and say that the size of ipv6-prefix alw= ays should be octets. Note that this makes a big difference when this information is encoded as a= 'structured' option (where additional data may follow). It is less of an i= ssue when this is the only field that is 'variable'. (Note that if we requi= re the octets, I would really declare this NOT to be v= ariable length as there is a length.) I also fear if we are not clear, we may end up with implementations that fa= il to interoperate. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Monday, April 08, 2013 1:32 PM To: 'Tomek Mrugalski'; 'Ted Lemon' Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Resp= ond by April 8, 2013 Tomek - Issue 1) this draft allows really stupid things, for example: you c= an release (or stop aggregating) prefix-pool when responding to REQUEST and= you can allocate (or rather aggregate) when responding to RELEASE Clarification - The key (or permit) of the above mechanism (or behavior) is= that OPTION_PREFIX_POOL try to support the 'real-time' setting (or aggrega= tion policy) change by the administrator.=20 Or do you want to simplify this mechanism? Tomek - Issue 2) Take this scenario: the PD for your last client connected = through the relay expires (rather than is being released). Your relay will = get stuck with outdated info, because there is no other DHCP traffic that s= erver can piggyback on. You could argue that leasequery can help here, but = how often would the relay do the query? This may introduce non-trivial amou= nt of extra traffic for the server to process. Clarification - The draft provide the mechanism that the relay can 'automat= ically withdraw the aggregation route' per its own table for tracking the s= tatus of the prefix pools if the PE needs the immediate 'sync' on those status.=20 The PE router acting as the relay agent MAY set up a table for the lease or status of the prefix pools on it according to the leases of the delegated customer prefixes within the prefix pools. The lease of the prefix pool SHOULD dynamically set to be the maximum lease of the delegated customer prefix within it. If there is no route entry directing to the customer network within the aggregation route associated with the prefix pool or the lease of prefix pool runs out, the PE router acting as the relay agent SHOULD automatically withdraw the aggregation route. Or do you want to simplify this mechanism? Tomek - So to answer your question: I *think* I understand the problem, I j= ust don't have enough experience in managing ISP networks to say whether th= is is the right solution to the problem or not. That's why I haven't expres= sed my support here. It is not that I'm opposing. I will count myself as "a= bstain". Let's stimulate more discussions on it. Tomek - There are other smaller issues as well: security considerations is = really empty,=20 Any more detailed review comments or suggested text on it? Tomek - ipv6-prefix field length is not precisely defined,=20 Not quite sure about the issue? pfx-pool-len: Length for the prefix pool in Bits ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero. Tomek - this draft talks about leasequery, but does not clearly define requ= estor behavior (I know that requestor in most cases is part of a relay, but= from protocol perspective these are separate entities),=20 Do you want a separate section on the 'requestor behavior'? Tomek - this draft repeats normative language from RFC3315 (e.g. "The relay= agent SHOULD include the Interface ID option"), it is not idnits clean etc= . Not quite sure about the issue? Sounds not difficult to fix it? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Monday, April 08, 2013 9:39 PM To: Ted Lemon Cc: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Resp= ond by April 8, 2013 On 08.04.2013 14:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski=20 > wrote: >> Today is the last day of this WGLC and the response has been abysmal=20 >> for now. >=20 > This is a bit frustrating-I think the problem that the prefix pool=20 > option is addressing is a real problem, but it's so leading edge > that I don't think a lot of people have really thought about it. I > think it's a problem that we ought to solve, but if nobody is willing=20 > to think about it, it's questionable that it's a good idea for the=20 > working group to push the solution. >=20 > How many people have actually reviewed the draft at this point and=20 > understand the problem it's trying to solve? I did review it (I think twice - first when it was individual draft and lat= er when it was adopted). I've posted couple comments on it some time ago, b= ut my understanding is that there are 2 outstanding issues that cannot be e= asily solved: Issue 1) this draft allows really stupid things, for example: you can relea= se (or stop aggregating) prefix-pool when responding to REQUEST and you can= allocate (or rather aggregate) when responding to RELEASE Issue 2) Take this scenario: the PD for your last client connected through = the relay expires (rather than is being released). Your relay will get stuc= k with outdated info, because there is no other DHCP traffic that server ca= n piggyback on. You could argue that leasequery can help here, but how ofte= n would the relay do the query? This may introduce non-trivial amount of ex= tra traffic for the server to process. So to answer your question: I *think* I understand the problem, I just don'= t have enough experience in managing ISP networks to say whether this is th= e right solution to the problem or not. That's why I haven't expressed my s= upport here. It is not that I'm opposing. I will count myself as "abstain". I think the biggest issue here is a lack of support. There's really nobody = saying "yes, I support this work moving forward". Gang sent some comments, = but he didn't state his support clearly. Even you are saying that this is i= mportant problem and it needs to be solved, but you didn't say "this is the= solution I want" or "I support this work". On a related note, there's a question in doc write-up: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As a chair, I wouldn't know how to answer it if we decided to somehow conti= nue forward with this document. So far it seems there's no consensus, and c= hairs even can't say that there's a strong concurrence of a few individuals= , because that "a few" would be just a subset of co-authors: Leaf and Ted. There are other smaller issues as well: security considerations is really e= mpty, ipv6-prefix field length is not precisely defined, this draft talks a= bout leasequery, but does not clearly define requestor behavior (I know tha= t requestor in most cases is part of a relay, but from protocol perspective= these are separate entities), this draft repeats normative language from R= FC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it = is not idnits clean etc. I did not had enough time to thoroughly review this draft, so I haven't pos= ted my review of -02. Some of the issues were reported earlier, but they ar= e still not resolved. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jouni.nospam@gmail.com Tue Apr 9 02:59:52 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047B621F8E7B; Tue, 9 Apr 2013 02:59:52 -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 znFejwvlgUwc; Tue, 9 Apr 2013 02:59:51 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id E71A221F9123; Tue, 9 Apr 2013 02:59:50 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e51so2852301eek.13 for ; Tue, 09 Apr 2013 02:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=UctFiYFhFkf420aVPuD7z9Ywc0RckOWP0YwOtSpdUAs=; b=x0+haXdgxbMjSnezNNmAthUD7nWXHssMkFVcmk5iM/dnvHULeA6Gyk0ZYNRzonRh0w bzxIbHtjQ8iq+yZGOObLLxMlt7A/rTUb0jCt9GB6Up6QSK7DcOFBYQEBqWKxD73ruEz9 uw/G/VW4XxnIw9WaY/MbA+sPS0A6IhScF9LdVmyOubBB6+KPXsipoDCAFxUo+bKm2dT1 vnObuhk6NOfAVL8QqbDIbrl4317InbRypg7dyWoHFzcM5X2ei4CINUCSYWxr/xYbbVnZ xqGGNuACuR29iilJHdQvuibiW0Zd8FvyhrT+Z8+Es0iFA6i+uE5s5IC+aGYQSbiAB4LI FkCQ== X-Received: by 10.14.216.2 with SMTP id f2mr58460601eep.44.1365501589930; Tue, 09 Apr 2013 02:59:49 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:39c5:a766:d0ea:341d? ([2001:1bc8:101:f101:39c5:a766:d0ea:341d]) by mx.google.com with ESMTPS id cd3sm27182663eeb.6.2013.04.09.02.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 02:59:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> Date: Tue, 9 Apr 2013 12:59:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1503) Cc: "" , Ted Lemon , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 09:59:52 -0000 On Apr 8, 2013, at 7:25 PM, Bernie Volz (volz) wrote: > (This is with chair hat off! I have to remember to indicate that.) > =20 > > having the server reflect the option back is easy > =20 > The ERO option can be specified to cause the server to send back the = option to the relay. I don=92t think we want to server to =93change=94 = the data in the option. > =20 > I wonder whether Jouni=92s concern is that the server may not send the = client the correct response? But in that case This is my concern and yes, it is not a concern of this document but the = future documents using the OPTION_RADIUS. > you need to assure your server is updated accordingly (to use the new = Radius attribute) and I don=92t see that this is really a concern for = this document? >=20 > We can=92t assume servers would know how to do something for something = that is not yet defined. The =93old=94 server ignoring the attribute in = the option is the correct action until it is updated. Sure. What I am after is a note stating that a _client_ must be prepared for a = reply from a server that does not provide adequate response/information = for all the RADIUS attributes the client included in the request. This = is solely meant for the future specifications using the OPTION_RADIUS. - JOuni > =20 > - Bernie > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ted Lemon > Sent: Monday, April 08, 2013 11:42 AM > To: Leaf Yeh > Cc: ; dhcwg > Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > =20 > On Apr 8, 2013, at 10:34 AM, Leaf Yeh wrote: > Jouni - it is possible in future when new attributes get added to = registry server silently discarding attributes may lead to a situation = where the server fails to provide enough information back to relay. > =20 > Also, having the server reflect the option back is easy; having it = make changes to the option is actually a protocol update, and probably = not a good idea. > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Tue Apr 9 05:38:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D182621F901B; Tue, 9 Apr 2013 05:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 bxSoMnPdFoQz; Tue, 9 Apr 2013 05:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5FA21F8FD6; Tue, 9 Apr 2013 05:38:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409123821.11361.29115.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 05:38:21 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-11.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, 09 Apr 2013 12:38:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Guidelines for Creating New DHCPv6 Options Author(s) : David W. Hankins Tomek Mrugalski Marcin Siodelski Sheng Jiang Suresh Krishnan Filename : draft-ietf-dhc-option-guidelines-11.txt Pages : 24 Date : 2013-04-09 Abstract: This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-option-guidelines-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomasz.mrugalski@gmail.com Tue Apr 9 05:47:12 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC32121F937E for ; Tue, 9 Apr 2013 05:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 aP+TNxQU7MPT for ; Tue, 9 Apr 2013 05:47:12 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BA21F937B for ; Tue, 9 Apr 2013 05:47:12 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so2882786ead.41 for ; Tue, 09 Apr 2013 05:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=fEVQpmnn6nf89xxeYdXW56RHF8MbgmvM0wgjr4AdR+c=; b=wfY/nfs/k0ZRsSqxVNrbD42StwHAuqtWCacRgMX6+RQxT3faqDcvOW05TmyhnORo3e ejM0PR/TsDB/puPvPWRPtPakHIPjQHJUb8sc38EMvlp4ZYoPSgI0nq/xWY2utXxbCqrg 5QzJcMgixUftb03QdMTeMqEs1aIFtsoNePuQKqVE3gGHsU9sGEo7c3XhrLCldz3DMEGW /RI8KRxKDe74UBuN8OPK12HLM/5oAZ1gJldKhQDKAFe1wYJsfDSbF2YvMOs9evMlHc2L 68iDVZ37uazSTuDCWyP4hlXkx//vkiAcSjiloVXmJpaz0YLt4APgz2/27Eq/OCEu/MQj 3C1w== X-Received: by 10.15.48.4 with SMTP id g4mr29735613eew.28.1365511631264; Tue, 09 Apr 2013 05:47:11 -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 f47sm37794323eep.13.2013.04.09.05.47.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 05:47:09 -0700 (PDT) Message-ID: <51640DC8.1080305@gmail.com> Date: Tue, 09 Apr 2013 14:47:04 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20130409123821.11361.29115.idtracker@ietfa.amsl.com> In-Reply-To: <20130409123821.11361.29115.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20130409144704882 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-11.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, 09 Apr 2013 12:47:13 -0000 Hi all, This version adds a couple new things: - specifies proposed sections for "Server/Client/Relay behavior". - whether a draft should or should not update RFC3315 - sub-options are now called encapsulated option (terminology from RFC3315) - many minor corrections Authors do not have anything else to add and think this work is ready. WGLC will be requested shortly. There's one minor formatting issue that slipped through in prefix-lenin section 5.3. It will be fixed in the next revision. Tomek On 09.04.2013 14:38, 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 : Guidelines for Creating New DHCPv6 Options > Author(s) : David W. Hankins > Tomek Mrugalski > Marcin Siodelski > Sheng Jiang > Suresh Krishnan > Filename : draft-ietf-dhc-option-guidelines-11.txt > Pages : 24 > Date : 2013-04-09 > > Abstract: > This document provides guidance to prospective DHCPv6 Option > developers to help them creating option formats that are easily > adoptable by existing DHCPv6 software. This document updates > RFC3315. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-option-guidelines-11 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From tomasz.mrugalski@gmail.com Tue Apr 9 05:49:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97221F8496 for ; Tue, 9 Apr 2013 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.659, 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 2EFcOrdCduX2 for ; Tue, 9 Apr 2013 05:49:37 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70421F84EF for ; Tue, 9 Apr 2013 05:49:37 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e50so2823413eek.30 for ; Tue, 09 Apr 2013 05:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=yICPx6zusZvIBXB/iWe4O7YMCfsOj/ZVhUJEpi35QYc=; b=lZ7ft2Z1FQLssC4xQZdVHtEtbeX2TRlBguiu/XePRSNJDkwGh8Y/OQkxlqly/aWHE1 GKR13VRTLz+dFeEbQ7QIJC4g1zcBuUbXywjc1H+xroPFpDuP92KoSAX5oQwXlI2J+jUI jT1KSlx9iwLe0KQFUSRWGxIvIX5a8NsGEelfM7DShceqvJxim43yVmocCbBRia8Tw6Dy pdQV7z4UJieWbX+mQjooAWXo/ZUD/kDYX2izs52lFGwwi0ePdbEITksWdjcpV9uQTBqO XIWbWbSBfftqtUyLG9PgKTP8uR0Z+LAjfUq3CN9AfKLXX+eX2ooIVwb3JoL3cpiMuEYk KAVw== X-Received: by 10.14.207.200 with SMTP id n48mr47260499eeo.4.1365511776520; Tue, 09 Apr 2013 05:49:36 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id s47sm37825992eeg.8.2013.04.09.05.49.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 05:49:35 -0700 (PDT) Message-ID: <51640E5C.4020900@gmail.com> Date: Tue, 09 Apr 2013 14:49:32 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg Subject: [dhcwg] WGLC request for draft-ietf-dhc-option-guidelines-11 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 Apr 2013 12:49:40 -0000 Bernie, authors of draft-ietf-dhc-option-guidelines-11 believe that this work is ready and would like to ask for WGLC. Can you announce one, please? Thanks, Tomek From tomasz.mrugalski@gmail.com Tue Apr 9 06:19:47 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D3121F904B for ; Tue, 9 Apr 2013 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 rrXhBsTra+9m for ; Tue, 9 Apr 2013 06:19:46 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9F121F85F5 for ; Tue, 9 Apr 2013 06:19:46 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so2901577ead.41 for ; Tue, 09 Apr 2013 06:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=8mlwBmO6obN8Q7If8N15lIiWtRJO6+KgmhmVc2GCU1U=; b=EDPgd8cjz/GxsBhj4qKWme38ZLeaLgWcJlxZzcOGvTuzS7vkk4YfThb7t5XoVySPKP xvyRfEtA/RlJVRvUuHBPv7eEoA5XTwEblYaKEf5oQnpVPkf0emNOZK98LewhOWqxArox ySZ4RPLk/H5MLka7jSstmcjW3s0J/fWy0dAIXdQ02bk+XRZdYrlLv7Q5a4YzdfFpCRiC 2+1IRRCgwp457iTUDlNESWGDEtjXTEmhR1ANXwF4k38Ly8AUxjE8VEVgzCpIExb+YtcU mqo5G2qHtOwrDKPhQuN4Dkz+XfzdUfKEObmtHJP4ojQF2pYpUN8ZwQ9Ljzv0LwUja3DC Mc8w== X-Received: by 10.14.107.69 with SMTP id n45mr38148266eeg.23.1365513585464; Tue, 09 Apr 2013 06:19:45 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id a1sm37999948eep.2.2013.04.09.06.19.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 06:19:44 -0700 (PDT) Message-ID: <5164156C.7020704@gmail.com> Date: Tue, 09 Apr 2013 15:19:40 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Leaf Yeh References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> In-Reply-To: <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> X-TagToolbar-Keys: D20130409151940398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:19:47 -0000 On 08.04.2013 19:31, Leaf Yeh wrote: > Tomek - Issue 1) this draft allows really stupid things, for example: you > can release (or stop aggregating) prefix-pool when responding to REQUEST and > you can allocate (or rather aggregate) when responding to RELEASE > > Clarification - The key (or permit) of the above mechanism (or behavior) is > that OPTION_PREFIX_POOL try to support the 'real-time' setting (or > aggregation policy) change by the administrator. > Or do you want to simplify this mechanism? No, the mechanism is more or less ok as it is now. What I'd like to see is a clarification about status. Something along the lines "Under normal circumstances the Status field should have value Active when responding to any client messages, except release and the status should have value Released only when responding to the Release message sent by the last active client connected via specific relay. Those recommendation may not apply if the server configuration has changed". > Tomek - Issue 2) Take this scenario: the PD for your last client connected > through the relay expires (rather than is being released). Your relay will > get stuck with outdated info, because there is no other DHCP traffic that > server can piggyback on. You could argue that leasequery can help here, but > how often would the relay do the query? This may introduce non-trivial > amount of extra traffic for the server to process. > > Clarification - The draft provide the mechanism that the relay can > 'automatically withdraw the aggregation route' per its own table for > tracking the status of the prefix pools if the PE needs the immediate 'sync' > on those status. > > The PE router acting as the relay agent MAY set up a table for the > lease or status of the prefix pools on it according to the leases of > the delegated customer prefixes within the prefix pools. The lease > of the prefix pool SHOULD dynamically set to be the maximum lease of > the delegated customer prefix within it. If there is no route entry > directing to the customer network within the aggregation route > associated with the prefix pool or the lease of prefix pool runs out, > the PE router acting as the relay agent SHOULD automatically withdraw > the aggregation route. > > Or do you want to simplify this mechanism? I must have missed that part. Ok, that makes sense. This also implies that the relays need to to deep packet inspection and parse IA_PD in relayed responses, but I suppose relays in this deployment scenario do this anyway, right? > Tomek - There are other smaller issues as well: security considerations is > really empty, > Any more detailed review comments or suggested text on it? Come on, there are some easy attack vectors here. What if the server sends out ::/0 in PREFIX_POOL option? Your relay will hijack the whole network? This means that if your DHCPv6 server is compromised you can start controlling (to some degree) traffic in your whole network. > Tomek - ipv6-prefix field length is not precisely defined, > Not quite sure about the issue? > > pfx-pool-len: Length for the prefix pool in Bits > ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 > octets in length. Bits outsides of the > pfx-pool-len, if included, MUST be zero. > Bernie had this concern and I tend to agree with him. For example you want to convey 2000:db8::/32 prefix. I can send an option with pfx-pool-len equal to 32, but the ipv6-prefix containing all 16 bytes. That option would be still conformant to this draft. The updated option-guidelines-11 draft says (or rather ought to say, but the text is not as clear as it should be) that the length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) > Tomek - this draft talks about leasequery, but does not clearly define > requestor behavior (I know that requestor in most cases is part of a relay, > but from protocol perspective these are separate entities), > > Do you want a separate section on the 'requestor behavior'? Yes. Please split actions taken by requestor into separate section. It can be subsection 5.1 if you like to. > Tomek - this draft repeats normative language from RFC3315 (e.g. "The relay > agent SHOULD include the Interface ID option"), it is not idnits clean etc. > > Not quite sure about the issue? Sounds not difficult to fix it? I didn't say that it is difficult to fix. My understanding is that documents that reach WGLC phase are expected to be idnits clean, unless there are good reasons for them to not be. When sending a draft to IESG that do not pass idnits, it is likely to get an brief response "please fix idnits" and nothing else. It sometimes takes a lot of time before IESG looks at such a draft again. Tomek From Ted.Lemon@nominum.com Tue Apr 9 06:53:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB31421F8A91; Tue, 9 Apr 2013 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 2m3YDbOnbpgI; Tue, 9 Apr 2013 06:53:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4021F8F33; Tue, 9 Apr 2013 06:53:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQdQdC7yHKPlMbY/0M1Rb6FZ/Kb3Wvj@postini.com; Tue, 09 Apr 2013 06:53:15 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 86DCC1B89FF; Tue, 9 Apr 2013 06:53:05 -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 7B936190061; Tue, 9 Apr 2013 06:53:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 06:53:05 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABBMQA= Date: Tue, 9 Apr 2013 13:53:04 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513A36C@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <536E2DDED7E1AF499082A21B5D21FCF2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Bernie Volz , dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 13:53:19 -0000 On Apr 9, 2013, at 5:59 AM, Jouni Korhonen wrote: > What I am after is a note stating that a _client_ must be prepared for a = reply from a server that does not provide adequate response/information for= all the RADIUS attributes the client included in the request. This is sole= ly meant for the future specifications using the OPTION_RADIUS. Yes, I think this would improve the document. From tomasz.mrugalski@gmail.com Tue Apr 9 07:31:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47B21F913E; Tue, 9 Apr 2013 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 BEScPioFCWNm; Tue, 9 Apr 2013 07:31:32 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id E477421F8F39; Tue, 9 Apr 2013 07:31:31 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id e53so3005951eek.9 for ; Tue, 09 Apr 2013 07:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=Bapb3zlhrTfTh3VOs/vR8+dLWwaAJisVLMNKORPeUN8=; b=p8wBjIslg+mZzAh8xS2S4l41iA0JuZk80tYmcRS9Yf/TWXj9J3Gx3dj56NdN956fNx Lq5iTeyVarfBJervWjcw+BZj9TjXyN5jdmNEcl3HyYkEPOXMT+G//RtQh0RbSUuwd27M 2WfpLBtSpy6ZMp6+De5TtMdsfrikE20gbUad69XodqESXANwDWpQ/ltRLLJLxUsAizrl GquLi25hPOUfWL3zhpMmqohmXvp88EG0IkcpULyJJIUgjYHc+C1yTBkTdgqWx5SsNtJV yceKW+vnumuqVqcotdsFquOJHQz6BJaohA4eUd9MjtV1igj9KAyx8Ox0A9cY9kLliC8C oDJQ== X-Received: by 10.15.21.1 with SMTP id c1mr60104763eeu.36.1365517890650; Tue, 09 Apr 2013 07:31:30 -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 d47sm38332200eem.9.2013.04.09.07.31.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 07:31:29 -0700 (PDT) Message-ID: <5164263E.50402@gmail.com> Date: Tue, 09 Apr 2013 16:31:26 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg@ietf.org, "" References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> In-Reply-To: X-TagToolbar-Keys: D20130409163126087 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 14:31:33 -0000 On 09.04.2013 11:59, Jouni Korhonen wrote: > What I am after is a note stating that a _client_ must be prepared > for a reply from a server that does not provide adequate > response/information for all the RADIUS attributes the client > included in the request. This is solely meant for the future > specifications using the OPTION_RADIUS. When clarifying that, we must remember to be explicit about which client or server (radius or dhcpv6) we are talking about here. Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 client. DHCPv6 client will never send it either. DHCPv6 Server will never send this option back, just receive it from the DHCPv6 relay. From Ted.Lemon@nominum.com Tue Apr 9 07:35:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982EB21F9357; Tue, 9 Apr 2013 07:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 BSOzZevwmguN; Tue, 9 Apr 2013 07:35:48 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2121F9351; Tue, 9 Apr 2013 07:35:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQnQtaR+E9czanszywpIslpm4ntl344@postini.com; Tue, 09 Apr 2013 07:35:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C28AF1B84E5; Tue, 9 Apr 2013 07:35:46 -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 BAD5A190061; Tue, 9 Apr 2013 07:35:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 07:35:46 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAAE1gA== Date: Tue, 9 Apr 2013 14:35:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> In-Reply-To: <5164263E.50402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BA4DDBD5FC67D419AD2C9532C274349@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 14:35:49 -0000 On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski wrote: > On 09.04.2013 11:59, Jouni Korhonen wrote: >> What I am after is a note stating that a _client_ must be prepared >> for a reply from a server that does not provide adequate >> response/information for all the RADIUS attributes the client >> included in the request. This is solely meant for the future >> specifications using the OPTION_RADIUS. > When clarifying that, we must remember to be explicit about which client > or server (radius or dhcpv6) we are talking about here. >=20 > Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 > client. DHCPv6 client will never send it either. DHCPv6 Server will > never send this option back, just receive it from the DHCPv6 relay. Oops, right. So it's the relay that may need to deal with an inappropriat= e response from the DHCP server? From volz@cisco.com Tue Apr 9 08:06:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA8821F9421 for ; Tue, 9 Apr 2013 08:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 Wx9GbYEVt6UG for ; Tue, 9 Apr 2013 08:06:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A2CDA21F9434 for ; Tue, 9 Apr 2013 08:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=771; q=dns/txt; s=iport; t=1365519977; x=1366729577; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=pcnXL0mp4BoITjPOILYRH/sEo6hH8xFWmWcV9fztNCY=; b=E3ugtH6rlPl2mf6jSA4rNdn8/uHiPFS/lRpCeDnYTHC08Z44nG57lWVI GhGtNN8x/b9XPOJknvGw81ZVQcsK4n0NhM907K6hE9gtq/rYk9dFwAI21 wVvlHZ7nK4jKRo70DZmhgPMTMRRzsOeF05GbbwEjIt2ArYHPZeXK0DIdr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFACktZFGtJV2d/2dsb2JhbABRgwY2gmS+YIEVFnSCIQEEOjEgASoUQiUCBBuIDAydOJESkDiOcTiCYGEDmBWPbIMLgig X-IronPort-AV: E=Sophos;i="4.87,439,1363132800"; d="scan'208";a="196774294" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 09 Apr 2013 15:06:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r39F6G5i008939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Apr 2013 15:06:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 10:06:16 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHONTPIl93nLZTEvUScfFC7lA3GSg== Date: Tue, 9 Apr 2013 15:06:15 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> In-Reply-To: <51640E5C.4020900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [161.44.65.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <93F692D4E2744E4EACAE0B8B5D6446C5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 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 Apr 2013 15:06:19 -0000 Folks, the authors of draft-ietf-dhc-option-guidelines-11, http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's ready for a WGLC. There's been discussion and comment already, but more eyes on and a "final" review of this work are required to advance it. This document is critical as it provides guidance to others in the IETF that may not be DHCP "experts" when they need to write a DHCP option internet-draft. At the time of this writing, there is no IPR reported against this draft. Please review the draft and indicate whether or not you feel it is ready to be published. Your response matters to the process, so please do respond. As Tomek is an author, I will evaluate consensus after April 24, 2013. Thanks! - Bernie From tomasz.mrugalski@gmail.com Tue Apr 9 08:08:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B104D21F936C; Tue, 9 Apr 2013 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 TK6PWleFuAQY; Tue, 9 Apr 2013 08:08:01 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC821F93A6; Tue, 9 Apr 2013 08:07:57 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id m14so2858685eaj.19 for ; Tue, 09 Apr 2013 08:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=k6O9KQrqqr31/qVj2T06lzy4gLhPYv15vycBG4nSBBY=; b=sypW6d7s4BYFzF2jmtw2WxNxz0H7AXEc74P9DuyvdPoKHWpIJC7H8FyES4eik04W2W GmsNSKKB4c/+ce9jai+C2I/Xp4mDV+RwwbU9TGHcgsogTB9+Efajh+KpGV6b1EBfHFRy uIUMh4hhVYuYebNLqvSPQZMCKjyoi2Dqz0lIFNPAE7CxUOVHmQc+2f7JTETptRrkrpAw 9S8SrzNDRHBTfpn59VVazdNzsZJVq7EY2CKLgOzsT1KTXZe+JYHqUsFx/RMvZRzg66sE rT+htAwrIcTGLYHa8EwyR4ZKW2z+M/051QPOj0VS39kkV9CG24tXKA0n1wvrhNyxEjae Q9+A== X-Received: by 10.15.83.73 with SMTP id b49mr17533416eez.25.1365520076927; Tue, 09 Apr 2013 08:07:56 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id bk42sm20283919eeb.3.2013.04.09.08.07.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 08:07:56 -0700 (PDT) Message-ID: <51642EC7.1010101@gmail.com> Date: Tue, 09 Apr 2013 17:07:51 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130409170751209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 15:08:01 -0000 On 09.04.2013 16:35, Ted Lemon wrote: > On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski > wrote: >> On 09.04.2013 11:59, Jouni Korhonen wrote: >>> What I am after is a note stating that a _client_ must be prepared >>> for a reply from a server that does not provide adequate >>> response/information for all the RADIUS attributes the client >>> included in the request. This is solely meant for the future >>> specifications using the OPTION_RADIUS. >> When clarifying that, we must remember to be explicit about which client >> or server (radius or dhcpv6) we are talking about here. >> >> Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 >> client. DHCPv6 client will never send it either. DHCPv6 Server will >> never send this option back, just receive it from the DHCPv6 relay. > > Oops, right. So it's the relay that may need to deal with an inappropriate response from the DHCP server? No. Is is the DHCP server. Relay/radius client get some attributes from radius server and then sends it along with the relayed message to the DHCP server. The DHCP server will use that information to select configuration parameters for the dhcp client. If the relay includes some Radius attributes the DHCP server does not recognize, the DHCP server should ignore that particular RADIUS attribute and use those it understands. Server will send response back to the DHCP client via DHCP relay, but that response will not include any RADIUS attributes. From leaf.yeh.sdo@gmail.com Tue Apr 9 08:10:08 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A544F21F942C; Tue, 9 Apr 2013 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 UWeZRljsLhve; Tue, 9 Apr 2013 08:10:08 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id D3EAD21F9397; Tue, 9 Apr 2013 08:10:07 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id u11so3847352pdi.36 for ; Tue, 09 Apr 2013 08:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=YMFBVt6RlEMYqMAE/eTpk4ZQeTrxY4dyfPaGI5aCZ1k=; b=tjke9XLIPhnDsXMNVow9xSNn/5ld3GGnKO6Fs7VWt/AO6c4Fh+yUT3Ym++I0iML9tJ QlIfUexe2LDjt4sRChGJotdByTeTCSbNCMkUT4ZOm4+pgH8DacamLO0ItceffAC78n5m X6Nsgd/rhKSZZ22vFYRgKSf6kaUgjnHTaHuXIQ8G5R+JE+9M9E0JKsZcugYBv4j3KvYZ h3Kkt4N9pjGCssPmjjTPe9fXwE1EWd/seznauc+r4cGqGzl/VSxhNAQn/xDz/4US2Ywf 2W+7SjEcmS+iEAC4O//H28jb7nW4qBJV3wbTIWZRRjlFBDVVKYOsfh0dmbkvqrOn7lBg 67rw== X-Received: by 10.68.12.7 with SMTP id u7mr2822264pbb.210.1365520199892; Tue, 09 Apr 2013 08:09:59 -0700 (PDT) Received: from PC ([221.219.107.201]) by mx.google.com with ESMTPS id yi5sm2546282pbb.25.2013.04.09.08.09.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 08:09:59 -0700 (PDT) From: "Leaf Yeh" To: "'Ted Lemon'" , "'Tomek Mrugalski'" References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> Date: Tue, 9 Apr 2013 23:09:47 +0800 Message-ID: <51642f47.85a3440a.0bb3.ffffd0ac@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAAE1gP//kLwQ Content-Language: zh-cn Cc: dhcwg@ietf.org, radext@ietf.org Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 15:10:09 -0000 Jouni - ...for all the RADIUS attributes the client included in the request. The DHCPv6 client never include the RADIUS attribute in this draft, the DHCPv6 relay include the RADIUS attribute from the RADIUS client. Ted - So it's the relay that may need to deal with an inappropriate response from the DHCP server? Tomek - DHCPv6 Server will never send this option back,... Tomek's words sounds right in most cases, including those cases described in Fig.1 & 2 of the draft. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Tuesday, April 09, 2013 10:36 PM To: Tomek Mrugalski Cc: ; Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski wrote: > On 09.04.2013 11:59, Jouni Korhonen wrote: >> What I am after is a note stating that a _client_ must be prepared >> for a reply from a server that does not provide adequate >> response/information for all the RADIUS attributes the client >> included in the request. This is solely meant for the future >> specifications using the OPTION_RADIUS. > When clarifying that, we must remember to be explicit about which > client or server (radius or dhcpv6) we are talking about here. > > Here's DHCPv6 point of view: This DHCPv6 option will never reach > DHCPv6 client. DHCPv6 client will never send it either. DHCPv6 Server > will never send this option back, just receive it from the DHCPv6 relay. Oops, right. So it's the relay that may need to deal with an inappropriate response from the DHCP server? _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Tue Apr 9 08:26:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A463521F9497; Tue, 9 Apr 2013 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il5LR9JaCKP8; Tue, 9 Apr 2013 08:26:11 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD421F9733; Tue, 9 Apr 2013 08:26:10 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so2962365eaj.35 for ; Tue, 09 Apr 2013 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=XlF+8zH0lY8pU4ObFfs4dBp316HCZHVbtdln9/G7MA8=; b=MZI2C92KCYQcC8CUBbCicnSqeKaXSYpV43RX9rYon0QVk2onOK3tXftoXKLounVJYK /BUZaIp/sQSnicekuVbGkba9VR+E1/93JJReumOoHEcq/ZcO6fG4knQPGVY6c/7QR5vb P6TG0OUw4NfG/0Vcc9+k9Ia76YHXmwv9iLojg1ERxYvixi+cYsgei9+lijUnfuG93FR0 Zvz+qyzIiaOIXApE2Bf/F5fnvVReNpcyhUhmGZ4/fKC+dJuqiCYS9AQwSbZ9oF/MUr+1 6bHSVbRiLTVFvXj99O8m8Nt4ir6YXG8BUla97I/Y7yDC2TVZ+XzuC42KQU+k1mkG5kA7 JyhQ== X-Received: by 10.15.99.201 with SMTP id bl49mr47250811eeb.43.1365521164284; Tue, 09 Apr 2013 08:26:04 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:52b:794d:ebdc:df24? ([2001:1bc8:101:f101:52b:794d:ebdc:df24]) by mx.google.com with ESMTPS id a41sm4397012eei.4.2013.04.09.08.26.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 08:26:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <5164263E.50402@gmail.com> Date: Tue, 9 Apr 2013 18:26:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1503) Cc: dhcwg@ietf.org, "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 15:26:11 -0000 On Apr 9, 2013, at 5:31 PM, Tomek Mrugalski = wrote: > On 09.04.2013 11:59, Jouni Korhonen wrote: >> What I am after is a note stating that a _client_ must be prepared >> for a reply from a server that does not provide adequate >> response/information for all the RADIUS attributes the client >> included in the request. This is solely meant for the future >> specifications using the OPTION_RADIUS. > When clarifying that, we must remember to be explicit about which = client > or server (radius or dhcpv6) we are talking about here. Ops. Good catch. Meant actually relay, not client, but wrote something = else :-)=20 > Here's DHCPv6 point of view: This DHCPv6 option will never reach = DHCPv6 > client. DHCPv6 client will never send it either. DHCPv6 Server will > never send this option back, just receive it from the DHCPv6 relay. I never said server sending the OPTION_RADIUS back. Still confirming = what I meant & asked to be clarified for future use of OPTION_RADIUS (and = whether my concern is valid to begin with): 0) Magic happens.. 1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS including attributes X,Y,Z. 2) DHCP Server does not understand Z and thus responses to the Relay with DHCP options/values based on X & Y only. 3) DHCP Relay receives the response but for it to send a meaningful reply to DHCP Client it would need some DHCP option/value in the reply that reflects the content of the RADIUS attribute Z (that was included into the request sent to Server). 4) what does DHCP Relay do now? - Jouni > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Apr 9 09:24:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21C621F8554; Tue, 9 Apr 2013 09:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 5jIWdDm9Ba3i; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 55F5321F8546; Tue, 9 Apr 2013 09:24:50 -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 DSNKUWRA0iiHQdBD+snbVOf4x7qi6MGftaCC@postini.com; Tue, 09 Apr 2013 09:24:50 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 0ED211B889A; Tue, 9 Apr 2013 09:24:50 -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 04819190061; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 09:24:50 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAA9AgIAAEG6A Date: Tue, 9 Apr 2013 16:24:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513AAEA@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> In-Reply-To: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <45CF9C5A6925F7429FEC29232C136A05@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 16:24:52 -0000 On Apr 9, 2013, at 11:26 AM, Jouni Korhonen wrote: > 2) DHCP Server does not understand Z and thus responses to the Relay > with DHCP options/values based on X & Y only. This is an administrative error. > 3) DHCP Relay receives the response but for it to send a meaningful > reply to DHCP Client it would need some DHCP option/value in > the reply that reflects the content of the RADIUS attribute Z > (that was included into the request sent to Server). The relay agent _never_ makes any decisions about what to send the client: = that decision is made on the server. Relay agent options can affect how t= he relay gets the response to the client, but do not affect the content of = the response. As a practical matter, it seems unlikely that a future RADIUS option would = affect _how_ the relay agent gets the response back to the client. So I t= hink this particular scenario is not a problem. Going back to the administrative error, it's an error because the administr= ation has configured the RADIUS server and relay to support something but n= eglected to update the DHCP server to support it. I think this failure mo= de is worth documenting, but ultimately it's not something that can be addr= essed in the spec other than as advice to administrators to make sure their= DHCP server supports the added functionality they are hoping to get out of= RADIUS. Sorry for my earlier slightly off-base remarks=97I have quite a few plates = spinning at the moment. From tomasz.mrugalski@gmail.com Tue Apr 9 09:38:35 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B921F9183; Tue, 9 Apr 2013 09:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 8eKTNkwFyVqw; Tue, 9 Apr 2013 09:38:34 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0121F9157; Tue, 9 Apr 2013 09:38:33 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so3017885ead.41 for ; Tue, 09 Apr 2013 09:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=cYHGYi5rE+krljM4WYCTcndyTz/+xn/SUCBQD4597Ks=; b=IebUx3+PcLUGKfEgeQxCdDqIarft9lZ5rk+ucqUY9ndUszVtPRjAEuAgcJMRd7jYGa Kv8p7knNNng4MD2utUExAqJNIAGPOWUiLHGuNpraBEPqOy+LmCGOWOukYj26LpiwkVM5 GD7SN3sMTt3jmh8naGVquQS09YD0VH0KiwxS7S0tQiK9fYCsYiqOvtoKZSjfXVO9IKYS BDRBA4vVMgqxtunOu4GzC/JtZyB00GNUhINopYWq3/qcWO1tqwVjVo57n0fRV8rhF7mc d6NC2eIVcrMRSExrDztbrboTzf5DNbazS8gHEsgVvzzlhpXX0Re5fEG773//ZIyxqykL w5lg== X-Received: by 10.14.5.137 with SMTP id 9mr61239229eel.30.1365525513212; Tue, 09 Apr 2013 09:38:33 -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 b5sm7262444eew.16.2013.04.09.09.38.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 09:38:32 -0700 (PDT) Message-ID: <51644403.9080206@gmail.com> Date: Tue, 09 Apr 2013 18:38:27 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jouni Korhonen References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> In-Reply-To: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> X-TagToolbar-Keys: D20130409183827957 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 16:38:35 -0000 On 09.04.2013 17:26, Jouni Korhonen wrote: >> Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 >> client. DHCPv6 client will never send it either. DHCPv6 Server will >> never send this option back, just receive it from the DHCPv6 relay. > > I never said server sending the OPTION_RADIUS back. You didn't, but someone in this thread mentioned something about sending the option back to the client. > Still confirming what I > meant & asked to be clarified for future use of OPTION_RADIUS (and whether > my concern is valid to begin with): > > 0) Magic happens.. > 1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS > including attributes X,Y,Z. > 2) DHCP Server does not understand Z and thus responses to the Relay > with DHCP options/values based on X & Y only. > 3) DHCP Relay receives the response but for it to send a meaningful > reply to DHCP Client it would need some DHCP option/value in > the reply that reflects the content of the RADIUS attribute Z > (that was included into the request sent to Server). > 4) what does DHCP Relay do now? Send the response back to the client, as usual. This is defined in RFC3315, section 20.2, which is a very simple section. Here's the relevant part: The relay agent extracts the message from the Relay Message option and relays it to the address contained in the peer-address field of the Relay-reply message. As simple as that: decapsulate and send to the client. Relay is not supposed to inspect the responses coming back from the server or act as judge of any sort (that response is good and the other is bad, because some DHCP option related to RADIUS attribute is not there). Some relays do deep packet inspection for various reasons (snooping addresses or prefixes for example), but that's an additional thing that do not affect the basic operation - send the response towards the client (or next relay closer to the client if there are more relays). Relays may produce warnings or send some alerts if certain option is missing, but they need to send the resonse back to the client anyway. Otherwise they violate RFC3315 and are not really DHCPv6 relays, but something that acts similar to DHCPv6 relay. Tomek From budmillwood@gmail.com Tue Apr 9 15:11:05 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9021F9953 for ; Tue, 9 Apr 2013 15:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWqwpNi1FTFA for ; Tue, 9 Apr 2013 15:11:04 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4627E21F995A for ; Tue, 9 Apr 2013 15:11:04 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so5392961wgg.0 for ; Tue, 09 Apr 2013 15:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7H2QLRNLfokzwzwOIcu/xMx5ZpYbpvkD8D9WezZg3fw=; b=qAX9Ia/uiXtEpmOZ+kxaTvmsdE0DKK3MfTk3wl93rDB43l/6Au0UR3yNcacfNgjpEu 0RdRNoccWdyP3S6D5cfZGiXv3BqhX2IqaVKCtJLO+HmY4yzurTunQFOLSvSnB4AfLw9c EjUr2wORET1zSP5cm9oLyxclOOcksn2bvR9UKfLqm6f7QJFgLe0zvRGXhPFnrdo8A//H 9Y7djiOalSp9AXUMcIfgJLA0HIKW/Vv608FV0DXziGwqahX1GHW4b31mFk4fyJkP1ZWW J4Yos/NHjOMXGY4Rm7W6V/Tx2JuY3jqYLDGfxj6hUqqSoaU7s59GFir3hXzYNTUbNxwV jB6A== MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr41661765wjb.38.1365545463297; Tue, 09 Apr 2013 15:11:03 -0700 (PDT) Sender: budmillwood@gmail.com Received: by 10.217.86.193 with HTTP; Tue, 9 Apr 2013 15:11:03 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> References: <51640E5C.4020900@gmail.com> <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> Date: Wed, 10 Apr 2013 00:11:03 +0200 X-Google-Sender-Auth: VBOTfr_z4RRUUvGb5uNeefqVyaE Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e013c6ab043bef904d9f4d477 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 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 Apr 2013 22:11:05 -0000 --089e013c6ab043bef904d9f4d477 Content-Type: text/plain; charset=ISO-8859-1 I'm so glad to see all this knowledge and experience finally codified in one place! Great work. - Figure 7 should say "variable", not "variale". - Section 10: "Introducing additional timers make deployment unnecessarily complex and should be avoided." * Change "make" to "makes" - Section 11 * I think the whole section is poorly written and poorly justified. How about: ---- 11. Configuration changes occur at fixed times In general, DHCPv6 clients only refresh configuration data from the DHCP server when the T1 timer expires. Although there is a RECONFIGURE mechanism that allows a DHCP server to request that clients initiate reconfiguration, support for this mechanism is optional and cannot be relied upon. In light of the above, when designing an option you should take into consideration the fact that your option may hold stale data that will only be updated at an arbitrary time in the future. ---- - Bud On Tue, Apr 9, 2013 at 5:06 PM, Bernie Volz (volz) wrote: > Folks, the authors of draft-ietf-dhc-option-guidelines-11, > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's > ready for a WGLC. There's been discussion and comment already, but more > eyes on and a "final" review of this work are required to advance it. > > This document is critical as it provides guidance to others in the IETF > that may not be DHCP "experts" when they need to write a DHCP option > internet-draft. > > At the time of this writing, there is no IPR reported against this draft. > > Please review the draft and indicate whether or not you feel it is ready > to be published. Your response matters to the process, so please do > respond. > > As Tomek is an author, I will evaluate consensus after April 24, 2013. > > Thanks! > > - Bernie > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --089e013c6ab043bef904d9f4d477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm so glad to see all this knowledge and experience f= inally codified in one place! Great work.

- Figure= 7 should say "variable", not "variale".

=
- Section 10: &qu= ot;Introducing additi= onal timers make=A0de= ployment unnecessarily complex and should be avoided."

=
* Change "ma= ke" to "makes"

- Se= ction 11

* I think the whole section is poorly written and poorly justified. How= about:

=
----
=
11. Configuration= changes occur at fixed times

=
In general, DHCPv= 6 clients only refresh configuration data from the DHCP server when the T1 = timer expires.
Although there is= a RECONFIGURE mechanism that allows a DHCP server to request that clients = initiate
reconfiguration,=A0support for this mechanism is optional and cannot be relied upon.<= /div>

=
In light of the a= bove, when designing an option you should take into consideration the fact = that your option
may hold stale da= ta that=A0will only b= e updated at an arbitrary time in the future.
----

- Bud


On Tue, Apr 9, 2013 at 5:06 PM, Bernie Volz (volz) <volz@ci= sco.com> wrote:
Folks, the authors of draft-ietf-dhc-option-= guidelines-11,
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelin= es-11, feel it's
ready for a WGLC. =A0There's been discussion and comment already, but m= ore
eyes on and a "final" review of this work are required to advance= it.

This document is critical as it provides guidance to others in the IETF
that may not be DHCP "experts" when they need to write a DHCP opt= ion
internet-draft.

At the time of this writing, there is no IPR reported against this draft.
Please review the draft and indicate whether or not you feel it is ready to be published. Your response matters to the process, so please do
respond.

As Tomek is an author, I will evaluate consensus after April 24, 2013.

Thanks!

- =A0 =A0 =A0 Bernie


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

--089e013c6ab043bef904d9f4d477-- From jouni.nospam@gmail.com Tue Apr 9 23:47:34 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593421F8C3C; Tue, 9 Apr 2013 23:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=1.799, 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 DShLm7-mf6GE; Tue, 9 Apr 2013 23:47:33 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1650D21F8E36; Tue, 9 Apr 2013 23:47:32 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id r10so188936lbi.36 for ; Tue, 09 Apr 2013 23:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=53Fc3f5BzeRoLkY8f4eU4O4mFE6vzx6srBhIxGjA43I=; b=lt/ZTD8OqevkWC2UuSHM21Gmj33ISzihZZ4G3l58UxNVl+j/UcsKBf6HLE/iyeIqeu Rkxd+1vDUrgPlDahYAqmK5/Vca/Lk8kvGQ6wJz7Yjf7Mux7xYh3vKL6QVDpEzXxa7hk0 7VxSuymupYjUW8VrpI0YJTDRfhGaTar9W3jWSP1LyjLTyuZed0LKvlRBSnMDAoCSx9HU +zUerNvHy+wPmEj5BKnd9luSvRWXEaa20hwv/4Y5c/xcclmzjQsaLQxFUMk5S7BrEhZj bnnpVfCmpNhGZkEbMjF/5DFns3eXwn3JNaXt0eyVrPrOv8eK5Eyv74IxTjzLsKG7cArd Pr0Q== X-Received: by 10.152.87.212 with SMTP id ba20mr405127lab.0.1365576452054; Tue, 09 Apr 2013 23:47:32 -0700 (PDT) Received: from [192.168.250.151] ([194.100.71.98]) by mx.google.com with ESMTPS id 10sm3328323laq.8.2013.04.09.23.47.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 23:47:30 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <51644403.9080206@gmail.com> Date: Wed, 10 Apr 2013 09:47:31 +0300 Content-Transfer-Encoding: 7bit Message-Id: <46E1E39C-4256-4AB3-B1B8-AA2701426F3A@gmail.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> <51644403.9080206@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1503) Cc: dhcwg@ietf.org, "" Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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 Apr 2013 06:47:34 -0000 > >> Still confirming what I >> meant & asked to be clarified for future use of OPTION_RADIUS (and whether >> my concern is valid to begin with): >> >> 0) Magic happens.. >> 1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS >> including attributes X,Y,Z. >> 2) DHCP Server does not understand Z and thus responses to the Relay >> with DHCP options/values based on X & Y only. >> 3) DHCP Relay receives the response but for it to send a meaningful >> reply to DHCP Client it would need some DHCP option/value in >> the reply that reflects the content of the RADIUS attribute Z >> (that was included into the request sent to Server). >> 4) what does DHCP Relay do now? > Send the response back to the client, as usual. This is defined in > RFC3315, section 20.2, which is a very simple section. Here's the > relevant part: > > The relay agent extracts the message from the Relay Message option > and relays it to the address contained in the peer-address field of > the Relay-reply message. > > As simple as that: decapsulate and send to the client. Ok. So this clears my concerns. Thanks for the patience convincing me ;-) - Jouni > > Relay is not supposed to inspect the responses coming back from the > server or act as judge of any sort (that response is good and the other > is bad, because some DHCP option related to RADIUS attribute is not > there). Some relays do deep packet inspection for various reasons > (snooping addresses or prefixes for example), but that's an additional > thing that do not affect the basic operation - send the response towards > the client (or next relay closer to the client if there are more > relays). Relays may produce warnings or send some alerts if certain > option is missing, but they need to send the resonse back to the client > anyway. Otherwise they violate RFC3315 and are not really DHCPv6 relays, > but something that acts similar to DHCPv6 relay. > > Tomek From leaf.yeh.sdo@gmail.com Thu Apr 11 20:33:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6721E8040 for ; Thu, 11 Apr 2013 20:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 O5kV3Ds45QSj for ; Thu, 11 Apr 2013 20:33:24 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 880AA21E803D for ; Thu, 11 Apr 2013 20:33:21 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so1182196pde.18 for ; Thu, 11 Apr 2013 20:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=mPY5ylLsc4o57tVAhNJte2LZG5CDyQfAe/VkA9Cq1Cs=; b=DPZK93ong3D2zP7dEneVHS4ZQCQmTUxlo24czJ3vMYzK6yob+C4TrCYx95VCpkRlCD NA7SoI9D3BVvPfYmD8flUsfTknCxcZVRMstpDV9AD8r6hibshu+kILV8JwYUBp15yusS l07b+ZuLktv4fp4QvL1PescliGFVCmTqY5qeswYu1vCAHDlYPm0ebstAF6+SGOr7Y+k+ /HyLA4xRDJGPJIClhj+BkGuOJ6IN4SexgZ+b4UOd/3lCtpTjnN1NhGK4F6q0bweN9Kfc E95hEIYu3/TcZIknI6fs6vliY5K2EHFPgewQr1NiabVs2RedtP5Q29T55moYrzdSDcGf hY7A== X-Received: by 10.66.122.97 with SMTP id lr1mr12983546pab.147.1365737601340; Thu, 11 Apr 2013 20:33:21 -0700 (PDT) Received: from PC ([221.219.107.201]) by mx.google.com with ESMTPS id ak1sm6650797pbc.10.2013.04.11.20.33.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Apr 2013 20:33:19 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , "'Tomek Mrugalski'" , "'Ted Lemon'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E184EC3C0@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EC3C0@xmb-rcd-x04.cisco.com> Date: Fri, 12 Apr 2013 11:33:05 +0800 Message-ID: <5167807f.41aa440a.0ea0.ffffbc8b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac40XnXnDVPmpx5gRjaCatWZiCQi/QAFaPQAAAi7VDAApROFwA== Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 03:33:25 -0000 I think the text in the draft (OPTION_PREFIX_POOL) sounds not wrong yet. For the further clarification complied with I-D.draft-ietf-dhc-option-guidelines, how about update the explanation of 'ipv6-prefix' in OPTION_PREFIX_POOL as follows? " ipv6-prefix: IPv6 prefix of the prefix pool, which is floor((pfx-pool-len+7)/8) octets in length per I-D.draft-ietf-dhc-option-guidelines. Bits outsides of the pfx-pool-len, if included, MUST be zero." Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, April 09, 2013 4:35 AM To: Leaf Yeh; 'Tomek Mrugalski'; 'Ted Lemon' Cc: dhcwg@ietf.org Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 pfx-pool-len: Length for the prefix pool in Bits ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero. The issue here is that if pfx-pool-len is 60, I can provide 0-16 octets of ipv6-prefix (or depending on how you interpret 8-16 octets). draft-ietf-dhc-option-guidelines-10 has: option-length is set to 1 + length of the IPv6 prefix. prefix6-len is one octet long and specifies the length in bits of the IPv6 prefix. Typically allowed values are 0 to 128. ipv6-prefix field is a variable length field that specifies the IPv6 prefix. This field is padded with zeros up to the nearest octet boundary when prefix6-len is not divisible by 8. Probably still not the best. I think we want to have the ipv6-prefix field to contain only octets. So, for a 60, we would want it to have 8 octets, not more or less? This is something we should clear up (also in draft-ietf-dhc-option-guidelines). The processing might be to initialize 16-octet buffer to all 0's, copy the ipv6-prefix octets (up to 16) into that buffer. The resulting value is the prefix. This would work and even allow the ipv6-prefix to be LESS than the prefix length when the bits are 0 (such as if 2001::/60 is sent, really only the first 2 octets are needed). Or, do we want to be more explicit and say that the size of ipv6-prefix always should be octets. Note that this makes a big difference when this information is encoded as a 'structured' option (where additional data may follow). It is less of an issue when this is the only field that is 'variable'. (Note that if we require the octets, I would really declare this NOT to be variable length as there is a length.) I also fear if we are not clear, we may end up with implementations that fail to interoperate. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Monday, April 08, 2013 1:32 PM To: 'Tomek Mrugalski'; 'Ted Lemon' Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Tomek - Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE Clarification - The key (or permit) of the above mechanism (or behavior) is that OPTION_PREFIX_POOL try to support the 'real-time' setting (or aggregation policy) change by the administrator. Or do you want to simplify this mechanism? Tomek - Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process. Clarification - The draft provide the mechanism that the relay can 'automatically withdraw the aggregation route' per its own table for tracking the status of the prefix pools if the PE needs the immediate 'sync' on those status. The PE router acting as the relay agent MAY set up a table for the lease or status of the prefix pools on it according to the leases of the delegated customer prefixes within the prefix pools. The lease of the prefix pool SHOULD dynamically set to be the maximum lease of the delegated customer prefix within it. If there is no route entry directing to the customer network within the aggregation route associated with the prefix pool or the lease of prefix pool runs out, the PE router acting as the relay agent SHOULD automatically withdraw the aggregation route. Or do you want to simplify this mechanism? Tomek - So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain". Let's stimulate more discussions on it. Tomek - There are other smaller issues as well: security considerations is really empty, Any more detailed review comments or suggested text on it? Tomek - ipv6-prefix field length is not precisely defined, Not quite sure about the issue? pfx-pool-len: Length for the prefix pool in Bits ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero. Tomek - this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), Do you want a separate section on the 'requestor behavior'? Tomek - this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. Not quite sure about the issue? Sounds not difficult to fix it? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Monday, April 08, 2013 9:39 PM To: Ted Lemon Cc: Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 On 08.04.2013 14:40, Ted Lemon wrote: > On Apr 8, 2013, at 8:32 AM, Tomek Mrugalski > wrote: >> Today is the last day of this WGLC and the response has been abysmal >> for now. > > This is a bit frustrating-I think the problem that the prefix pool > option is addressing is a real problem, but it's so leading edge > that I don't think a lot of people have really thought about it. I > think it's a problem that we ought to solve, but if nobody is willing > to think about it, it's questionable that it's a good idea for the > working group to push the solution. > > How many people have actually reviewed the draft at this point and > understand the problem it's trying to solve? I did review it (I think twice - first when it was individual draft and later when it was adopted). I've posted couple comments on it some time ago, but my understanding is that there are 2 outstanding issues that cannot be easily solved: Issue 1) this draft allows really stupid things, for example: you can release (or stop aggregating) prefix-pool when responding to REQUEST and you can allocate (or rather aggregate) when responding to RELEASE Issue 2) Take this scenario: the PD for your last client connected through the relay expires (rather than is being released). Your relay will get stuck with outdated info, because there is no other DHCP traffic that server can piggyback on. You could argue that leasequery can help here, but how often would the relay do the query? This may introduce non-trivial amount of extra traffic for the server to process. So to answer your question: I *think* I understand the problem, I just don't have enough experience in managing ISP networks to say whether this is the right solution to the problem or not. That's why I haven't expressed my support here. It is not that I'm opposing. I will count myself as "abstain". I think the biggest issue here is a lack of support. There's really nobody saying "yes, I support this work moving forward". Gang sent some comments, but he didn't state his support clearly. Even you are saying that this is important problem and it needs to be solved, but you didn't say "this is the solution I want" or "I support this work". On a related note, there's a question in doc write-up: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As a chair, I wouldn't know how to answer it if we decided to somehow continue forward with this document. So far it seems there's no consensus, and chairs even can't say that there's a strong concurrence of a few individuals, because that "a few" would be just a subset of co-authors: Leaf and Ted. There are other smaller issues as well: security considerations is really empty, ipv6-prefix field length is not precisely defined, this draft talks about leasequery, but does not clearly define requestor behavior (I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities), this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. I did not had enough time to thoroughly review this draft, so I haven't posted my review of -02. Some of the issues were reported earlier, but they are still not resolved. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Fri Apr 12 03:15:37 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0D421F89E2 for ; Fri, 12 Apr 2013 03:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.325 X-Spam-Level: * X-Spam-Status: No, score=1.325 tagged_above=-999 required=5 tests=[AWL=-3.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, RELAY_IS_221=2.222] 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 YOmJZFMKMPR8 for ; Fri, 12 Apr 2013 03:15:37 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB99921F89D3 for ; Fri, 12 Apr 2013 03:15:36 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id s35so1086276dak.20 for ; Fri, 12 Apr 2013 03:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=VLhsrjPBSVzZkAT+1JMIf+BI9ykWoeW7IpumQF8O2Nk=; b=KOpcs922Al7oAoQ37T74zzayppEkqiHw3/vPECbQf1Aluotj2GoMFCvMuE+s/jYCEI uNn5ls3dqn50eVBcIfdudEmOcg8ltUhGKUSG2fxj7D9Ik1plnf6/yalVyxl919zt0y4M 5RLeD6bq9RQpJzsB1XZ0kq1ilk9402ITX9lmJmFrAAhJ4ml63NhXDjEdhr3qOGjtmqPR eBPd4ZUKMQbHVVVEDDy708nL8WkYC15chSwQ8R47ilTxdcSEGPc0MsgKBs57YJ4gDuOq +uimjBa0uleoToYxxV2KDJyOrU88RY9bEUVsa1IkgIpFvpZrT9xJ61QbBd52UEKhu24o oquA== X-Received: by 10.68.251.194 with SMTP id zm2mr13582182pbc.81.1365761735672; Fri, 12 Apr 2013 03:15:35 -0700 (PDT) Received: from PC ([221.219.107.201]) by mx.google.com with ESMTPS id wi6sm8000247pbc.22.2013.04.12.03.15.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Apr 2013 03:15:34 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> In-Reply-To: <5164156C.7020704@gmail.com> Date: Fri, 12 Apr 2013 18:15:26 +0800 Message-ID: <5167dec6.86f1440a.146b.2032@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac41JOgioF5ht16xR6uvEQwXxyTc9ACCF2Jw Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 10:15:37 -0000 Tomek - What I'd like to see is a clarification about status. Something along the lines "Under normal circumstances the Status field should have value Active when responding to any client messages, except release and the status should have value Released only when responding to the Release message sent by the last active client connected via specific relay. Those recommendation may not apply if the server configuration has changed". Clarification - The definition of the 'Statue' of the prefix pool is in section 4 of this draft. If the administrative policy on the server permits to support route aggregation on the relay agent, the status of prefix pool can be determined by the delegated prefixes within the associated prefix pool: If there is one delegated prefix within the pool that has a valid lease, the status of the prefix pool will be 'Active'; otherwise, the status of the prefix pool is 'Released'. If the administrative policy on the server does not permit to support route aggregation on the relay agent, the status of the prefix pool will always be 'Released'. So we can't say 'Under normal circumstances the Status field should have value Active when responding to any client messages'. I supposed the status of the prefix pool is 'Released' from the beginning. After there is a client got a delegated (PD) prefix with a valid lease, then the status of prefix pool turns to be 'Active', or we can say the prefix pool also got a 'valid' lease, if the administrator of server configure it to support OPTION_PREFIX_POOL. If the server is configured to not support OPTION_PREFIX_POOL, then all the prefix pools are in the status of 'Released', which sounds equal to 'no status', as what we have now on the server. Tomek - This also implies that the relays need to to deep packet inspection and parse IA_PD in relayed responses, but I suppose relays in this deployment scenario do this anyway, right? Yes. PE needs to set up the dedicated route entries for each customer network behind CE per the PD prefixes (and its leases) in IA_PDs. Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? Your relay will hijack the whole network? ... The relay's behavior is still under control by the server. If it got the wrong configuration, the server could also send out ::/0 in the IA_PD. So this may sound an administration error. We just want the prefix pools not configure to be ::/0 or any overlap between them. I feel a little stuck on the exact text you want. How about 'The administrator of the DHCPv6 server should pay more attention to the configuration of the prefix pools, for examples, a. ::/0 may cause a big routing problem in the whole ISP network; b. the configuration of prefix pool should avoid overlap in the address plan, and etc.' ? I am not quite sure... Tomek - Bernie had this concern and I tend to agree with him... the length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my reply to Bernie's email. Thanks for your suggestion here. Do we need more explanation on the mathematic function of floor() ? :-) Tomek - ...(I know that requestor in most cases is part of a relay, but from protocol perspective these are separate entities)...Yes. Please split actions taken by requestor into separate section. It can be subsection 5.1 if you like to. Do you mean add section 5.1 "Leasequery Requestor Behavior" in the section 5 "Relay Agent Behavior" (just for an editorial change)? Do you want section 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? Tomek - ...this draft repeats normative language from RFC3315 (e.g. "The relay agent SHOULD include the Interface ID option")... After searching and reading, I still can't find this sentence in RFC3315. Best Regards, Leaf -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] Sent: Tuesday, April 09, 2013 9:20 PM To: Leaf Yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 On 08.04.2013 19:31, Leaf Yeh wrote: > Tomek - Issue 1) this draft allows really stupid things, for example: > you can release (or stop aggregating) prefix-pool when responding to > REQUEST and you can allocate (or rather aggregate) when responding to > RELEASE > > Clarification - The key (or permit) of the above mechanism (or > behavior) is that OPTION_PREFIX_POOL try to support the 'real-time' > setting (or aggregation policy) change by the administrator. > Or do you want to simplify this mechanism? No, the mechanism is more or less ok as it is now. What I'd like to see is a clarification about status. Something along the lines "Under normal circumstances the Status field should have value Active when responding to any client messages, except release and the status should have value Released only when responding to the Release message sent by the last active client connected via specific relay. Those recommendation may not apply if the server configuration has changed". > Tomek - Issue 2) Take this scenario: the PD for your last client > connected through the relay expires (rather than is being released). > Your relay will get stuck with outdated info, because there is no > other DHCP traffic that server can piggyback on. You could argue that > leasequery can help here, but how often would the relay do the query? > This may introduce non-trivial amount of extra traffic for the server to process. > > Clarification - The draft provide the mechanism that the relay can > 'automatically withdraw the aggregation route' per its own table for > tracking the status of the prefix pools if the PE needs the immediate 'sync' > on those status. > > The PE router acting as the relay agent MAY set up a table for the > lease or status of the prefix pools on it according to the leases of > the delegated customer prefixes within the prefix pools. The lease > of the prefix pool SHOULD dynamically set to be the maximum lease of > the delegated customer prefix within it. If there is no route entry > directing to the customer network within the aggregation route > associated with the prefix pool or the lease of prefix pool runs out, > the PE router acting as the relay agent SHOULD automatically withdraw > the aggregation route. > > Or do you want to simplify this mechanism? I must have missed that part. Ok, that makes sense. This also implies that the relays need to to deep packet inspection and parse IA_PD in relayed responses, but I suppose relays in this deployment scenario do this anyway, right? > Tomek - There are other smaller issues as well: security > considerations is really empty, Any more detailed review comments or > suggested text on it? Come on, there are some easy attack vectors here. What if the server sends out ::/0 in PREFIX_POOL option? Your relay will hijack the whole network? This means that if your DHCPv6 server is compromised you can start controlling (to some degree) traffic in your whole network. > Tomek - ipv6-prefix field length is not precisely defined, Not quite > sure about the issue? > > pfx-pool-len: Length for the prefix pool in Bits > ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 > octets in length. Bits outsides of the > pfx-pool-len, if included, MUST be zero. > Bernie had this concern and I tend to agree with him. For example you want to convey 2000:db8::/32 prefix. I can send an option with pfx-pool-len equal to 32, but the ipv6-prefix containing all 16 bytes. That option would be still conformant to this draft. The updated option-guidelines-11 draft says (or rather ought to say, but the text is not as clear as it should be) that the length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) > Tomek - this draft talks about leasequery, but does not clearly define > requestor behavior (I know that requestor in most cases is part of a > relay, but from protocol perspective these are separate entities), > > Do you want a separate section on the 'requestor behavior'? Yes. Please split actions taken by requestor into separate section. It can be subsection 5.1 if you like to. > Tomek - this draft repeats normative language from RFC3315 (e.g. "The > relay agent SHOULD include the Interface ID option"), it is not idnits clean etc. > > Not quite sure about the issue? Sounds not difficult to fix it? I didn't say that it is difficult to fix. My understanding is that documents that reach WGLC phase are expected to be idnits clean, unless there are good reasons for them to not be. When sending a draft to IESG that do not pass idnits, it is likely to get an brief response "please fix idnits" and nothing else. It sometimes takes a lot of time before IESG looks at such a draft again. Tomek From internet-drafts@ietf.org Fri Apr 12 03:44:35 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182F521F8C00; Fri, 12 Apr 2013 03:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, 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 Tz9KNCyBED-m; Fri, 12 Apr 2013 03:44:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9572F21F8B15; Fri, 12 Apr 2013 03:44:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130412104432.24255.76935.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 03:44:32 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-11.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 Apr 2013 10:44:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agent Author(s) : Leaf Y. Yeh Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-radius-opt-11.txt Pages : 11 Date : 2013-04-12 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Apr 12 04:47:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F373121F8A40; Fri, 12 Apr 2013 04:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxo104-Z2geF; Fri, 12 Apr 2013 04:47:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7490021F8A3F; Fri, 12 Apr 2013 04:47:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 28AC526429E; Fri, 12 Apr 2013 13:47:36 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 043724C024; Fri, 12 Apr 2013 13:47:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 12 Apr 2013 13:47:35 +0200 From: To: Tomek Mrugalski , "dhcwg@ietf.org" Date: Fri, 12 Apr 2013 13:47:35 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac4wkmnmG3CvbrVoTqWsHqLYpp3TBwG3qLrQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> In-Reply-To: <515C69A4.7000903@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "Softwires \(softwires@ietf.org\)" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:47:39 -0000 Dear all, (I cc sofwtire as this work is also relevant for the working group.) I do not support this work as it induces more complexity compared to just d= efining adequate option in dhcpv6. Defining one container or few DHCPv6 opt= ions is much more simpler that the proposed approach.=20 Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e >Tomek Mrugalski >Envoy=E9=A0: mercredi 3 avril 2013 19:41 >=C0=A0: dhcwg@ietf.org >Objet=A0: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > >Hi all, > >This draft is a result of the discussion we had during last meeting in >Orlando. We have very productive discussion about IPv4 hosts >configuration in IPv6-only network. After we reached what looked like a >consensus in the meeting room, couple folks volunteered to write down >the draft that summarizes that perceived consensus. This draft is a >product of this effort. > >As requested by authors, we are announcing adotion call on >draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to >confirm whether there is WG consensus to adopt this work as DHC WG >draft. Please state whether or not you're in favor of the adoption by >replying to this mail. If you are not in favor, please also state your >objections in your response. This adoption call will complete on 2013-04- >17. > >Regards, >Bernie & Tomek > >On 03.04.2013 19:20, Marcin Siodelski wrote: >> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am asking >> for adoption of this document by DHC WG. >> >> The latest version (-01) is available here: >> >> http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6- >01.txt >> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 >> >> This document describes a mechanism whereby IPv4 client obtains its >> configuration from the DHCPv4 server separated from the client by IPv6- >> only network having DHCPv6 service. This mechanism is frequently >> referred as "DHCPv4-over-DHCPv6". >> >> The DHCPv4 client's request is carried in the newly defined DHCPv6 >> messages/option to/from the server and can be sent either through a >> relay or directly. >> >> Cheers, >> Marcin >> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Fri Apr 12 05:12:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6F321F8712 for ; Fri, 12 Apr 2013 05:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAtGfTd9-Uzn for ; Fri, 12 Apr 2013 05:12:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AE18421F8700 for ; Fri, 12 Apr 2013 05:12:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 627BD2DC0D6; Fri, 12 Apr 2013 14:12:05 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 48D9835C048; Fri, 12 Apr 2013 14:12:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 12 Apr 2013 14:12:05 +0200 From: To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Date: Fri, 12 Apr 2013 14:12:04 +0200 Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHONTPIl93nLZTEvUScfFC7lA3GSpjSfZow Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C108@PUEXCB1B.nanterre.francetelecom.fr> References: <51640E5C.4020900@gmail.com> <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 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 Apr 2013 12:12:07 -0000 Dear all, I read this version. Thanks for the work. IMHO, http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#sectio= n-8 does not reflect the consensus of the WG on these matters. Especially, = it does not reflect what has been discussed during the call for adoption fo= r http://datatracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding= /.=20 Saying IP Address is superior to FQDN is just not that trivial to say. It i= s not a universal statement and it makes deployment assumptions. I don't wa= nt to reiterate what have been discussed for draft-boucadair-dhc-address-na= me-encoding, archives are there to extract the exact position of the wg.=20 The text in Section 8 still assume DNS is the only available name resolutio= n library; this is not anymore true. Section 2 of draft-boucadair-dhc-addre= ss-name-encoding provides a much more balanced comparison.=20 Instead of picking a winner (IP Address vs. FQDN), it is more valuable to i= nvestigates ways to accommodates operational needs rather than imposing a d= eployment choice for entities deploying servers and making use of a given o= ption. Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e >Bernie Volz (volz) >Envoy=E9=A0: mardi 9 avril 2013 17:06 >=C0=A0: dhcwg@ietf.org >Objet=A0: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by >April 24 > >Folks, the authors of draft-ietf-dhc-option-guidelines-11, >http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's >ready for a WGLC. There's been discussion and comment already, but more >eyes on and a "final" review of this work are required to advance it. > >This document is critical as it provides guidance to others in the IETF >that may not be DHCP "experts" when they need to write a DHCP option >internet-draft. > >At the time of this writing, there is no IPR reported against this draft. > >Please review the draft and indicate whether or not you feel it is ready >to be published. Your response matters to the process, so please do >respond. > >As Tomek is an author, I will evaluate consensus after April 24, 2013. > >Thanks! > >- Bernie > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From mellon@fugue.com Sat Apr 13 12:19:09 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6570021F8E49 for ; Sat, 13 Apr 2013 12:19:09 -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 N8-VwPPFUDhE for ; Sat, 13 Apr 2013 12:19:08 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5921F8BF8 for ; Sat, 13 Apr 2013 12:19:08 -0700 (PDT) Received: from [IPv6:2001:470:88a3::bd54:d46b:3ab1:b647] (unknown [IPv6:2001:470:88a3:0:bd54:d46b:3ab1:b647]) by toccata.fugue.com (Postfix) with ESMTPSA id A0295238050F; Sat, 13 Apr 2013 15:19:06 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Apr 2013 15:19:05 -0400 Message-Id: <77D82DCE-2C81-48B4-B4E9-EA30CCC73449@fugue.com> To: "" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dhcwg] draft-lemon-dhc-topo-conf X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 19:19:09 -0000 I just submitted a new document to the tracker that attempts to document = existing practice with respect to how DHCP options are derived and sent = to clients in modern DHCP servers. This is a first draft, and probably = needs some new examples. People on this mailing list will, I suspect, = find it difficult to remain awake while reading it because it is such = old hat to us, but it's been brought to my attention recently that not = everybody in the IETF is an expert on DHCP server configuration; this = document is an attempt to provide a short, pithy tutorial for IETF = document writers who are interested in understanding how DHCP is used in = practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lemon-dhc-topo-conf There's also a htmlized version available at: http://tools.ietf.org/html/draft-lemon-dhc-topo-conf-00 From stenc@s-carlsen.dk Sun Apr 14 02:52:18 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D875021F8FB8 for ; Sun, 14 Apr 2013 02:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnREati3FH0W for ; Sun, 14 Apr 2013 02:52:18 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7621F8FA7 for ; Sun, 14 Apr 2013 02:52:17 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fefe:16ca]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 031623484 for ; Sun, 14 Apr 2013 11:52:13 +0200 (CEST) Message-ID: <516A7C4C.8010207@s-carlsen.dk> Date: Sun, 14 Apr 2013 11:52:12 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <77D82DCE-2C81-48B4-B4E9-EA30CCC73449@fugue.com> In-Reply-To: <77D82DCE-2C81-48B4-B4E9-EA30CCC73449@fugue.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------010708020801090709000803" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 09:52:18 -0000 This is a multi-part message in MIME format. --------------010708020801090709000803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi I think this is a good initiative and a good start. I hope there will be some additional contributions from other perspectives. My first comment is to Figure 1, you have 4 relays. They are all placed in the gateways, it may be beneficial to place at least one of them away from the gateway to indicate that this is also a valid configuration. On 13/04/13 21:19, Ted Lemon wrote: > I just submitted a new document to the tracker that attempts to document existing practice with respect to how DHCP options are derived and sent to clients in modern DHCP servers. This is a first draft, and probably needs some new examples. People on this mailing list will, I suspect, find it difficult to remain awake while reading it because it is such old hat to us, but it's been brought to my attention recently that not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a short, pithy tutorial for IETF document writers who are interested in understanding how DHCP is used in practice. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lemon-dhc-topo-conf > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lemon-dhc-topo-conf-00 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010708020801090709000803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

I think this is a good initiative and a good start. I hope there will be some additional contributions from other perspectives.

My first comment is to Figure 1, you have 4 relays. They are all placed in the gateways, it may be beneficial to place at least one of them away from the gateway to indicate that this is also a valid configuration.


On 13/04/13 21:19, Ted Lemon wrote:
I just submitted a new document to the tracker that attempts to document existing practice with respect to how DHCP options are derived and sent to clients in modern DHCP servers.   This is a first draft, and probably needs some new examples.   People on this mailing list will, I suspect, find it difficult to remain awake while reading it because it is such old hat to us, but it's been brought to my attention recently that not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a short, pithy tutorial for IETF document writers who are interested in understanding how DHCP is used in practice.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lemon-dhc-topo-conf

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-lemon-dhc-topo-conf-00

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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------010708020801090709000803-- From tomasz.mrugalski@gmail.com Sun Apr 14 05:26:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A83921F8EDF for ; Sun, 14 Apr 2013 05:26:11 -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 6BpdcBd2B5kC for ; Sun, 14 Apr 2013 05:26:11 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5DD21F8F6D for ; Sun, 14 Apr 2013 05:26:11 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so2085839pbc.3 for ; Sun, 14 Apr 2013 05:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=kn2UwYl51i8fa000oYP9EZxt7wdUDB999Z1u13iCQoc=; b=RF8TU6gxI64eFlzbHUVJCWSJb1JYtefpHIdXTyiDGU2sb1t7+RVaXASLoQav6BJzwH gACQlsbONSiXwW1kFoWZYJV48ZNoS+E+BsDBYpBGQxbFmoL41wKPLyFahbTuQAv5kguf E6q2qroKg+zrsu+6Ki3Ch2OKELKoj9oVG/rqKxM2SM8cGgLjsauykfjya6BYTirRHOVH 1g4qunMcDlLhFQhVtJMrRtelaIxM8p/TeZpMohVw3La633LP29IFiAYWix6Ta4wtJKQ1 KSMzL4ZMy3R2SqUCL/CTS7d4L/enAaq8KAEfG/5PDIH6NaWSONPTmUxnu8rYvIB44aDC OeOw== X-Received: by 10.66.123.105 with SMTP id lz9mr24834237pab.137.1365942370874; Sun, 14 Apr 2013 05:26:10 -0700 (PDT) Received: from thomson-osx.lan (dsl092-002-166.sfo1.dsl.speakeasy.net. [66.92.2.166]) by mx.google.com with ESMTPS id jk11sm16230073pbb.0.2013.04.14.05.26.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 05:26:10 -0700 (PDT) Message-ID: <516AA05E.3070801@gmail.com> Date: Sun, 14 Apr 2013 05:26:06 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leaf Yeh References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> In-Reply-To: <5167dec6.86f1440a.146b.2032@mx.google.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 12:26:11 -0000 On 13-04-12 03:15, Leaf Yeh wrote: > Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? Your > relay will hijack the whole network? ... > > The relay's behavior is still under control by the server. If it got the > wrong configuration, the server could also send out ::/0 in the IA_PD. So > this may sound an administration error. We just want the prefix pools not > configure to be ::/0 or any overlap between them. I feel a little stuck on > the exact text you want. How about 'The administrator of the DHCPv6 server > should pay more attention to the configuration of the prefix pools, for > examples, a. ::/0 may cause a big routing problem in the whole ISP network; > b. the configuration of prefix pool should avoid overlap in the address > plan, and etc.' ? I am not quite sure... Administrator mistake is one concern, the other one is that DHCPv6 server may become an attractive attack target when prefix-pool is deployed. How about "Misconfigured or compromised DHCPv6 server can cause relays to start announcing arbitrary prefixes, including default routes, which could lead to traffic hijack."? > Tomek - Bernie had this concern and I tend to agree with him... the length > of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) > See my reply to Bernie's email. Thanks for your suggestion here. Do we need > more explanation on the mathematic function of floor() ? :-) I don't think so. A potential implementor who doesn't know what floor() function does should probably consider starting a career in some other industry. :-) > Tomek - ...(I know that requestor in most cases is part of a relay, but from > protocol perspective these are separate entities)...Yes. Please split > actions taken by requestor into separate section. It can be subsection 5.1 > if you like to. > > Do you mean add section 5.1 "Leasequery Requestor Behavior" in the section 5 > "Relay Agent Behavior" (just for an editorial change)? Do you want section > 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? Yes to both. > Tomek - ...this draft repeats normative language from RFC3315 (e.g. "The > relay agent SHOULD include the Interface ID option")... > > After searching and reading, I still can't find this sentence in RFC3315. It is in prefix-pool-opt-02, section 5, second paragraph. Text from prefix-pool-opt-02 is an imprecise subset of behaviour described in RFC3315, section 20.1.1, second paragraph. Here's the difference: RFC3315: relay MUST include interface-id if the link-address in server's response is not sufficient to select downlink interface. prefix-pool-opt-02: relay SHOULD include interface-id, so the the server can identify the relay itself (tomek: that's wrong. Interface-id is for interface or subnet identification, not relay identification. Relay-id is used for that purpose, see RFC5460, section 5.4.1) if the server would not like to use the link-address field specified in RELAY-FORW message (tomek: that imprecise or wrong. The server is not at liberty to "not use link-address field". There's a specific algorithm defined in section 11 of RFC3315 that the server must follow it). Tomek From Ted.Lemon@nominum.com Sun Apr 14 07:07:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F105721F90B1 for ; Sun, 14 Apr 2013 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 OHcCXo2z74HO for ; Sun, 14 Apr 2013 07:07:24 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC79421F90B8 for ; Sun, 14 Apr 2013 07:07:23 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUWq4G2UnQkzWo3SvivvANw5tO8sZ+4mc@postini.com; Sun, 14 Apr 2013 07:07:23 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 475F91B80D8 for ; Sun, 14 Apr 2013 07:07:23 -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 3D9BE190061; Sun, 14 Apr 2013 07:07:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 14 Apr 2013 07:07:18 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOHvI3k2MoTLQa0uUqsbeRb1B3pjV79oAgABHQwA= Date: Sun, 14 Apr 2013 14:07:17 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775146765@mbx-01.win.nominum.com> References: <77D82DCE-2C81-48B4-B4E9-EA30CCC73449@fugue.com> <516A7C4C.8010207@s-carlsen.dk> In-Reply-To: <516A7C4C.8010207@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775146765mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 14:07:25 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775146765mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 14, 2013, at 5:52 AM, Sten Carlsen > wrote: My first comment is to Figure 1, you have 4 relays. They are all placed in = the gateways, it may be beneficial to place at least one of them away from = the gateway to indicate that this is also a valid configuration. It's certainly a "valid" configuration, but I don't think it's a common con= figuration, and I'm trying to describe current practice in this document, n= ot what you "could" do. For that, you ought to buy the DHCP Handbook! := ) Seriously, do you know of common deployments where the relay is configured = that way? Out side of academic experiments, I'm not aware of any. I've = done that as a hack when I wanted to make the relay do something unusual, b= ut it's always been a temporary measure on the way to getting the feature i= nto the place where I really want it, not as an end in itself. --_000_8D23D4052ABE7A4490E77B1A012B630775146765mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 14, 2013, at 5:52 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
My first comment is to Figure 1, you have 4 relays. They are all placed in th= e gateways, it may be beneficial to place at least one of them away from th= e gateway to indicate that this is also a valid configuration.

It's certainly a "valid" configuration, but I don't think it= 's a common configuration, and I'm trying to describe current practice in t= his document, not what you "could" do.   For that, you ought= to buy the DHCP Handbook!   :)

Seriously, do you know of common deployments where the relay is config= ured that way?   Out side of academic experiments, I'm not aware of an= y.   I've done that as a hack when I wanted to make the relay do somet= hing unusual, but it's always been a temporary measure on the way to getting the feature into the place where I really wa= nt it, not as an end in itself.

--_000_8D23D4052ABE7A4490E77B1A012B630775146765mbx01winnominum_-- From tomasz.mrugalski@gmail.com Sun Apr 14 07:54:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFD821F90F6 for ; Sun, 14 Apr 2013 07:54:17 -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 fRpohBc2vJpo for ; Sun, 14 Apr 2013 07:54:16 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id BF1DE21F90CE for ; Sun, 14 Apr 2013 07:54:16 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id um15so2077203pbc.8 for ; Sun, 14 Apr 2013 07:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=9KszFQkoLPIdBRHr6lPfEh59S5FPbyk10CHovpsw7WM=; b=nwdmcsBxjel66uQ9pWM4nVemvWqQbKIfKZSFDtrJ7Fxbo5LAwEawQ8jnWpEEt2+dRI xTfoqjpRALJU3vnY38AoCoyfLb/OFCVjn7qH5nmxVl8L2W2OxK/AUHTiyQAVbZxLv28P XEZp2WD/XEUHzXH/BpOSwm0gq7srJ/F1DSgxZBlQ8db7OGUaHQYJ2ivWyOcKV9Faast+ wjY7eqiEumjhyHDEF6yTxmO9dQrlCIuA4vkjWBUmvhxqzN7v43AZTI4qUkLmJtE2P2nN Mulaii9d/2iiiiPslX+aITbsXwLrN/hfgTDp/Iybhbu+FaLTBgSvhhbvBbpiagyhl8Wt Xr7g== X-Received: by 10.66.48.201 with SMTP id o9mr24959391pan.196.1365951256534; Sun, 14 Apr 2013 07:54:16 -0700 (PDT) Received: from thomson-osx.lan (dsl092-002-166.sfo1.dsl.speakeasy.net. [66.92.2.166]) by mx.google.com with ESMTPS id be10sm16567399pbd.30.2013.04.14.07.54.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 07:54:15 -0700 (PDT) Message-ID: <516AC316.4020005@gmail.com> Date: Sun, 14 Apr 2013 07:54:14 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: DHC WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28 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 Apr 2013 14:54:17 -0000 Folks, The authors of draft-ietf-dhc-container-opt-07 feel it's ready for WGLC. This draft was active around 2010, but then expired. It was revived (-06) in December 2012 and updated recently (-07). The last version is more explicit about which options are not allowed in the container option. Please review the draft and indicate whether or not you feel it is ready to be published. We have been getting very anemic responses to working group last calls recently. Your response matters, so please do respond. Silent support is not enough. If not enough people voice their support, the document will not advance. Simply saying "I support this work" is enough. Providing detailed review is better, but not necessary. Bernie and I will evaluate consensus after April 28. At the time of this writing, there is no IPR reported against this draft. Tomek From volz@cisco.com Sun Apr 14 13:13:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0632421F8FF5 for ; Sun, 14 Apr 2013 13:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF06wVkp0mNf for ; Sun, 14 Apr 2013 13:13:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AABAF21F859B for ; Sun, 14 Apr 2013 13:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17012; q=dns/txt; s=iport; t=1365970398; x=1367179998; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=y8eu0ruDjsptU+xlOzYf+3PZwEVBmr7Jt6qKoxZlEFo=; b=Oo1+UTXOwJMeLXQr27nU0zdzskrJh+VA0ncjZeut0EOLc9FfnDxxz+ls rpgeusmA1nP30kovnSj2DE37A8kUvhTcnlZMEIWd5+jtQYhIdoNX0WsCO fY06UvUaLP/VGcP/DiSltC1XSjIFB4h82I7cAGgIKz8sLyTUjZrn0/G4n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFALYMa1GtJV2d/2dsb2JhbABHCYMGNsFAgQUWdIIfAQEBBAEBATctBAMLDAYBCBEEAQELFAkuCxQJCQEEDgUIE4d5DLljjUsRA4EHJgsNglphA5J+OoRuj3CDC4FqAgcXBhg X-IronPort-AV: E=Sophos;i="4.87,471,1363132800"; d="scan'208";a="198608554" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 14 Apr 2013 20:13:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3EKDH4d000564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Apr 2013 20:13:17 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sun, 14 Apr 2013 15:13:17 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: Ac45PhADpiAsKiu0RbSUFR9Qrk6K2g== Date: Sun, 14 Apr 2013 20:13:16 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18504BC7@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 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 Apr 2013 20:13:21 -0000 NOTE: WG co-chair hat OFF ... these are my comments as an individual "membe= r" of the WG. I fully support this work and would like to see it advance. And I have done= a somewhat careful review with the comments below. 1. I think the "updates RFC 3315" in the header and also in the Abstract is= wrong and should be removed. There is nothing in this document that specif= ically changes anything in RFC 3315. 2. In section 3 - add text in brackets: accessing the external Internet via local assist services that [the] network must also provide (such as domain name servers, or routers). ... this is one [of the] main reason[s] for the use of DHCPv6 in corporate enterprises. 3. In section 5 - replace/add text in brackets: This [means] that implementations will [likely] be able to reuse code pa= ths designed to support the other options. Another choice would be "This assumes that implementations will be able ...= ". Drop the last sentence as it is not true: "It is only a list of option form= at fragments which are used in two or more options." 4. Section 5.1: For: o DHCPv6 server unicast address [RFC3315] You need to also add "(a single address only)". 5. Section 5.3:=20 Sometimes there is a need to convey [a/an] IPv6 prefix. The information= to be carried by [such] an option includes the 128-bit IPv6 prefix together Wonder whether the equation should be: ( + 7) /8 As written, it may be misevaluated as division has higher preference than a= ddition (usually). We could further clarify the integer portion is used, bu= t I think that is clear as you can't have 6.5 octets. In the example, prefix-len should be prefix6-len: For example, the prefix 2001:db8::/60 would be encoded with an option-length of 9, prefix6-len would be set to 60, the ipv6-prefix would be 8 octets and would contains octets 20 01 0d b8 00 00 00 00. And replace the last sentence paragraph with: It should be noted that the IAPREFIX option defined by [RFC3633] uses a constant length prefix. The concern about option length was not well understood at the time of its publication. 6. Section 5.7 - I wonder whether it is worth to remind future writers they= MUST document the allowed encoding for this data. 7. Section 5.8 - I wonder whether it is worth to point out that this really= is a specific encoding instances of section 5.7, and in this case the enco= de can also support multiple instances as the DNS wire encoded format allow= s on to determine the end of a FQDN (because of the 0 "." field). 8. Section 6: The following is a bit odd ... Therefore the conditional formatting requires new code to be written, as well as introduces an implementation problem; as it requires that all speakers implement all current and future conditional formats. Conditional formatting is not recommended, except in cases where the DHCPv6 option has already been deployed experimentally, and all but one conditional format is deprecated. Can we replace this with: Conditional formatting requires new code to be written and complicates future interoperability should new conditional formats be added; and existing code has to ignore conditional formats that it does not support. Do we even want to suggest that "deployed experimentally" is useful? It is = an experiment so why would the 'official' IETF option use it? I would just = suggest not to go there - I don't want someone arguing 'well, I experimente= d in my network using option 55555 with this conditional format and this do= cument lets me keep that conditional format." 9. Section 8. Reword: Section 7), so one of them must be chosen. This section is intended as a help to make an informed decision in that regard. To: Section 7), so one of them must be chosen. This section is intended to help make an informed decision in that regard. And also: FQDN imposes [a] number of additional failure modes and issues that should be dealt with: And I still have concerns about #4 and #7 in this list. They don't really m= ake that much sense as written. Perhaps for 4 the intent was: 4. The client has to determine for which address families DNS is queried?= A or AAAA records or both? And if both, which is preferred? Client impleme= ntations are encouraged to follow [RFC 6555] if both address families are p= ossible. For 7, I think this issue refers to encoding that is not DNS wire format - = as I don't understand what the issue is for IDNs for DNS wire encoding? But= this goes back to my issue with #6 for Section 5.7 that documenting the en= coding is important. I suspect this issue 7 goes back to when UTF-8 or ASCII was intended as a p= ossible 'string' encoding (as then addresses in string format could be sent= ). The text in Section 8 never really discussed 'FQDN' encoding, but there = really is the question as to what does "FQDN" mean? I don't think we genera= lly mean it to be an ASCII representation of a v4 or v6 address. So perhaps this means that 'FQDN' is a bad term used in this section or tha= t we need additional text to discuss this alternate form for a "string" enc= oding of an ASCII representation for a v4/v6 address or a FQDN. (The 2nd pa= ragraph in this section 8 starts out with "On the specific subject of desir= ing to configure a value using a FQDN instead of a binary IP address" - yet= Med's original proposal wasn't a choice between the two but an ENCODING th= at allowed an FQDN or "ascii" address. So perhaps we have not really answer= ed his quest for that? (Which may be why he sent his response to this WGLC.= ) Perhaps for 7 in the list, remove it and add a new paragraph to end of the = section (feel free to edit and extend): Some may be tempted to use a "string" encoding which would allow the string= representation of an address or a domain name. However, this MUST be avoid= ed as it has many potential security and implementation issues, some of whi= ch are: 1. How is this data encoded? Especially consider International Domain Names= and non-ASCII characters in domain names. 2. How is this data validated? While it is easy to determine whether the st= ring representation of an IPv6 (or IPv4) address is specified, it is more d= ifficult to validate domain names as valid FQDNs. And, is a terminal "dot" = assumed for the domain name or are relative names allowed (if so, this of c= ourse raises the question of the search list being used by the client). 10. Section 9: From the implementation perspective, it is easier to implement encapsulated option rather than sub-option, as the implementer[s] do not ... Such encapsulation is not limited to one level. There is For this 3rd paragraph "sub-option" has returned. I really would like to se= e this replaced by encapsulated and not to use sub-option as this is encaps= ulation! Such encapsulation is not limited to one level. There is at least one defined option that is encapsulated twice: Identity Association for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such delegated prefix may contain an excluded prefix range that is represented by PD_EXCLUDE option that is conveyed as encapsulated inside the IAPREFIX option (PD_EXCLUDE, defined in [RFC6603]). It seems= awkward to refer to such an option as a doubly encapsulated option, therefore "encapsulated option" term is typically used, regardless of the nesting level. 11. Section 10: Can we replace "nodes" and "node" with "clients" and "client"? This section= starts out with "DHCP is a protocol designed for provisioning nodes." ... = This should be "DHCP is a protocol designed for provisioning clients.". Also: generate [client]-specific information. Such [a] solution does not intr= oduce any additional state for the server and therefore scales better. ... For renewing other parameters, please use [the] Information Refresh Time Option (defined in [RFC4242]). Introducing additional timers make deployment unnecessarily complex and [SHOULD] be avoided. One note here is that RFC 4242 states "It is only used in Reply messages in= response to Information-Request messages." - so a "Renew" messages cannot = use it (the text says "For renewing" which doesn't necessarily imply a Rene= w message.). 12. Section 11: nonce. That means that [the] provisioning server is the only one that c= an initiate reconfiguration. Other servers do not know [the nonce] and [th= erefore] cannot trigger reconfiguration. Therefore the only reliable way for clients to refresh their configuration is to wait until T1 [or Information Refre= sh Time] expires. 13. Section 12: example of such [a] case is a home network with a connection to two independent ISPs. 14. Section 14: DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through its use of link-local addresses, it [avoids] many of the requirements. [C]ommon sense still applies here. It is better to split distinct values into separate [octets] rather than propose overly complex bit shifting operations to save [] several bits (or is recommended to clarify (with normative language) whether a given DHCPv6 option may appear once or multiple times. [The default assumption is only once.] 15. Section 15: Such [] text is discouraged as there are several issues with it. First, it assumes that client implementation that supports a given option will always want to use it. This is not true. The second and more important reason is that such [] text essentially duplicates Either at the end of this section (or possibly section 14), do we want to p= rovide any guidance about whether the ordering of multiple instances of any= option can be assumed to have significance? I don't think RFC 3315 clarifi= ed this and in many cases it doesn't matter (such as IA_NA/IA_PD ordering).= But, while we didn't do it and probably don't recommend doing so, but the = DNS Servers (addresses) option could have only allowed a single address and= we could have allowed multiple instances. In this case, order would likely= be significant. I think this goes back to saying - if order is important to you, do it in y= our option(s) - have a list of items rather than a single item. And, we should simply say that the order of options, even multiple instance= s of the same option, is NOT significant and MUST NOT be assumed. 16. Section 17: I'd move the requestor text from the first paragraph into the start of the = 2nd. The reason is that you start with three major entities, then add the f= ourth, but the say "those three major components". So, I think the followin= g makes more sense: There are three major entities in DHCPv6 protocol: server, relay agent, and client. It is very helpful for [implementers] to include separate sections that describe operation for those three major [entities]. Even when a given entity does not participate, it is useful to have a very short section stating that it must not send a given option and must ignore it when received. There is also a separate entity called requestor, which is a special client-like type that participates in leasequery protocol [RFC5007] and [RFC5460]. [A] similar section for [the] requestor is not required, unless the new option has anything to do with requestor (or it is likely that the reader may think that is has). It should be noted that while i= n [the] majority of Later, replace be with by: appear in certain message or being sent [by] certain entities. And: Typically new options are requested by clients and assigned by [the] server, so there is no specific relay behavior. Nevertheless it is good to include a section for relay agent [behavior] and simply state 17. Section 17.1 How about naming this section "Sample DHCPv6 Client Behavior Text"? And: Client[s] MAY request option foo, as defined in [RFC3315], sections And: Optional text (if the option contains FQDN): If the client request[s] an option that conveys [an] FQDN, it is expected that [the] content[s] of t= hat option will be resolved using DNS. Hence the following text may be useful: Client that requests option foo SHOULD also request option OPTION_DNS_SERVERS specified in [RFC3646]. Client[s] MUST discard option foo if it is invalid (i.e. did not pass validation steps defined in Section X.Y). 18. Section 17.2 How about naming this section "Sample DHCPv6 Server Behavior Text"? Optional text: Server[s] MUST NOT send more than one instance of foo option. Optional text (if server is never supposed to receive option foo): Server[s] MUST ignore incoming foo option. 19. Section 18 Authors often ask themselves a question whether their proposal updates exist RFCs, especially [[RFC3315]]. [In April 2013]=20 there were [about 80] options defined. (I think it best not to be that specific, as the count will continue to cha= nge and the 'time of writing' may move.) changes something in already defined behavior, e.g. servers must discard incoming messages if option foo is invalid or missing, then the "updates" phrase is warranted. I don't think this is really a good example. I think it should be when exis= ting behavior (as documented in RFC 3315) is replaced by new behavior (such= as the stateful -issues draft does). Adding new options or messages that m= ay have different behavior still just extends. Only when text is replaced o= r modified is updates appropriate. For example, RFC 6644 and draft-ietf-dhc= -dhcpv6-solmaxrt-update clearly updates RFC 3315 - they replace existing wi= th new text. Perhaps these are better examples? 20. Section 19: endpoints and men in the middle. Other authentication mechanisms may ... least to man-in-the-middle attacks from within the network, even Should be consistent and use "man-in-the-middle" in both places? (That's at= least what Wikipedia uses - http://en.wikipedia.org/wiki/Man-in-the-middle= _attack). And in the following replace supporting with support: without requiring symmetric key pairs or [support] from any key And in v6 we have no broadcast so best to replace broadcast with multicast = (may also want to drop 'local'?) security. An IP address field might be made to carry a loopback address, or local [multicast] address, and depending on the protocol 21. Section 22: Usually 2119 and 3115 would be Normative References? But this is sometimes = a judgment call. 22. What might be missing? I wonder whether more might be said about Relay options and that they too u= se the same number space as client/server options? Perhaps this is already = clear enough in RFC 3315. 23. Summary: A great job on this document and I'm glad it hopefully will be finished soo= n! Thanks much Tomek for taking it over and working to get it this far. Muc= h of what I have commented on is minor and would be addressed by RFC-Editor= anyway (there is likely a lot more they will do too!). But, I do have a fe= w significant comments that I hope can be addressed in a -12 and will not r= equire another WGLC. I do hope that for those that have read this far that you also look over th= e document as it is important work!! Regards, - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Tuesday, April 09, 2013 11:06 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by Ap= ril 24 Folks, the authors of draft-ietf-dhc-option-guidelines-11, http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's r= eady for a WGLC. There's been discussion and comment already, but more eye= s on and a "final" review of this work are required to advance it. This document is critical as it provides guidance to others in the IETF tha= t may not be DHCP "experts" when they need to write a DHCP option internet-= draft. At the time of this writing, there is no IPR reported against this draft. Please review the draft and indicate whether or not you feel it is ready to= be published. Your response matters to the process, so please do respond. As Tomek is an author, I will evaluate consensus after April 24, 2013. Thanks! - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Sun Apr 14 22:49:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3C421F8EFD; Sun, 14 Apr 2013 22:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 sUhEBF7wvxmJ; Sun, 14 Apr 2013 22:48:49 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id B737E21F8EF1; Sun, 14 Apr 2013 22:48:46 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un15so2308079pbc.40 for ; Sun, 14 Apr 2013 22:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=OVJg4O93QLAfqtxV+MgX3gsvHvuZN7Z8Q/4KSMMGd0k=; b=Hi/KFJwBwc04iewfod9MYu+30DADYCyvOaqgpUmJtdWB99bgPgKNnoZQf9RumXV1O0 cR0PMKV+01oMLNmvQ3Cm6oVz3VHS56KgQ/X40DJc2y3QctP3Ol/kWfYg3l+9w/c/rvvb 9tok1/B1aOhrORywIwLDXGAQ+wbhsYjqWoTcKeoTH3my9ax5BRxWgisDXQJtF3tP5yT+ XC+2ncxPtY2Q1t7ZrCLNTGIx3bpugwF7XQKXNNP7UImmHeXe3KyjCeOriOqwf+ufI2xr 2Ul8NHXWiPZ2waCLkDpTPq+DOxyU6QKa+ckqEZkBG7iSrevOenv5HWMf+gV6YxowCqBF DsnA== X-Received: by 10.68.176.37 with SMTP id cf5mr27181394pbc.173.1366004926475; Sun, 14 Apr 2013 22:48:46 -0700 (PDT) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id lf12sm20599867pab.13.2013.04.14.22.48.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 22:48:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 15 Apr 2013 13:48:35 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5EAE6839-8D2A-455B-840A-3D0B0E7637C4@gmail.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org" , "Softwires \(softwires@ietf.org\)" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 05:49:07 -0000 Dear Med,=20 Thanks for your response. Here is my understanding. IMHO, defining options in DHCPv6 seems to introduce less complexity in = protocol. However, we do not know for now which options are needed in = the future. If we have to port DHCPv4 options into DHCPv6, how many = times should we do the work? Like one new option per 2 years, or = redefining all DHCPv4 options into DHCPv6 at one time? The proposed = solution tries to avoid polluting the DHCPv6 option space, which is = necessary for transition in DHCP. Another point is that, defining option(s) / container would require the = DHCPv6 engine to handle DHCPv4 options, which would introduce more = complexity to the logic and implementation of end points. The proposed = solution leverages the DHCPv4 engine for DHCPv4 messages / options and = DHCPv6 engine for DHCPv6 messages / options. The end points would = compatible to both DHCPv4 process and DHCPv6 process. This is more = suitable for the transition. A third consideration is, in the case of IPv6 transition, the DHCP = client (on the tunnel endpoint) is bound to be modified. We think it = better to modify the client completely for the transition purpose. Last but not the least, the proposed solution is based on the DHCPv6 = infrastructure, which has been deployed in operators' networks.=20 The DHCPv4 over DHCPv6 mechanism is an architectural development for = DHCP protocol to meet the requirements for configuring IPv4 parameters = across the IPv6 network. We think it is important for the DHC WG to work = on it. Best Regards, Qi Sun On 2013-4-12, at =E4=B8=8B=E5=8D=887:47, = wrote: > Dear all, >=20 > (I cc sofwtire as this work is also relevant for the working group.) >=20 > I do not support this work as it induces more complexity compared to = just defining adequate option in dhcpv6. Defining one container or few = DHCPv6 options is much more simpler that the proposed approach.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la = part de >> Tomek Mrugalski >> Envoy=C3=A9 : mercredi 3 avril 2013 19:41 >> =C3=80 : dhcwg@ietf.org >> Objet : [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 >>=20 >> Hi all, >>=20 >> This draft is a result of the discussion we had during last meeting = in >> Orlando. We have very productive discussion about IPv4 hosts >> configuration in IPv6-only network. After we reached what looked like = a >> consensus in the meeting room, couple folks volunteered to write down >> the draft that summarizes that perceived consensus. This draft is a >> product of this effort. >>=20 >> As requested by authors, we are announcing adotion call on >> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated = to >> confirm whether there is WG consensus to adopt this work as DHC WG >> draft. Please state whether or not you're in favor of the adoption by >> replying to this mail. If you are not in favor, please also state = your >> objections in your response. This adoption call will complete on = 2013-04- >> 17. >>=20 >> Regards, >> Bernie & Tomek >>=20 >> On 03.04.2013 19:20, Marcin Siodelski wrote: >>> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am = asking >>> for adoption of this document by DHC WG. >>>=20 >>> The latest version (-01) is available here: >>>=20 >>> = http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6- >> 01.txt >>> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 >>>=20 >>> This document describes a mechanism whereby IPv4 client obtains its >>> configuration from the DHCPv4 server separated from the client by = IPv6- >>> only network having DHCPv6 service. This mechanism is frequently >>> referred as "DHCPv4-over-DHCPv6". >>>=20 >>> The DHCPv4 client's request is carried in the newly defined DHCPv6 >>> messages/option to/from the server and can be sent either through a >>> relay or directly. >>>=20 >>> Cheers, >>> Marcin >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Sun Apr 14 22:56:30 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C89021F9305; Sun, 14 Apr 2013 22:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 9JHfG1VBLzxC; Sun, 14 Apr 2013 22:56:29 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4721F92FC; Sun, 14 Apr 2013 22:56:29 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id mc17so2351495pbc.28 for ; Sun, 14 Apr 2013 22:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=AFRrLz9PUEntw9G38s4iv06ezoNaah9B3+6lVRhaYB0=; b=FALZvIYNAG4kkvVvHEFYD3Mqgsqi26UyBWwmLNEcVRoa+DSW5/AAOmd7aEjkZBlDLU mNWRbvMkEN7HzZLUgH/GEsBx8z0NOmeun0qVsE2SBtKDlh4ikFPRkIxXVGsUroVjfVAY WiqsNAUlUqILhJJOtM3bxpW9xFSGILTjhiwx8Eu9HWEUqLeVj0oKG6dwlyRj+nqZu8E7 0iuzJoJl/9SjedBSHdrp6TGbeyV7LDUsYx5y92yv5eFxNPiXcvcyOz0kWJTKpLjCf401 He+fXhucmB5/PyPDz5LGjH0oC+V9e76Mo3LdwH+FZfNBi1iVALasiN2CrzK9NDkW8mzz r3sg== X-Received: by 10.68.135.231 with SMTP id pv7mr26882477pbb.108.1366005386026; Sun, 14 Apr 2013 22:56:26 -0700 (PDT) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id ky10sm20587959pab.23.2013.04.14.22.56.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 22:56:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 15 Apr 2013 13:56:14 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org" , "Softwires \(softwires@ietf.org\)" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 05:56:30 -0000 Dear Med,=20 Thanks for your response. Here is my understanding. IMHO, defining options in DHCPv6 seems to introduce less complexity in = protocol. However, we do not know for now which options are needed in = the future. If we have to port DHCPv4 options into DHCPv6, how many = times should we do the work? Like one new option per 2 years, or = redefining all DHCPv4 options into DHCPv6 at one time? The proposed = solution tries to avoid polluting the DHCPv6 option space, which is = necessary for transition in DHCP. Another point is that, defining option(s) / container would require the = DHCPv6 engine to handle DHCPv4 options, which would introduce more = complexity to the logic and implementation of end points. The proposed = solution leverages the DHCPv4 engine for DHCPv4 messages / options and = DHCPv6 engine for DHCPv6 messages / options. The end points would = compatible to both DHCPv4 process and DHCPv6 process. This is more = suitable for the transition. A third consideration is, in the case of IPv6 transition, the DHCP = client (on the tunnel endpoint) is bound to be modified. We think it = better to modify the client completely for the transition purpose. Last but not the least, the proposed solution is based on the DHCPv6 = infrastructure, which has been deployed in operators' networks.=20 The DHCPv4 over DHCPv6 mechanism is an architectural development for = DHCP protocol to meet the requirements for configuring IPv4 parameters = across the IPv6 network. We think it is important for the DHC WG to work = on it. Best Regards, Qi Sun (Sorry for resending, try to synchronize with softwire ML...) On 2013-4-12, at =E4=B8=8B=E5=8D=887:47, = wrote: > Dear all, >=20 > (I cc sofwtire as this work is also relevant for the working group.) >=20 > I do not support this work as it induces more complexity compared to = just defining adequate option in dhcpv6. Defining one container or few = DHCPv6 options is much more simpler that the proposed approach.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la = part de >> Tomek Mrugalski >> Envoy=C3=A9 : mercredi 3 avril 2013 19:41 >> =C3=80 : dhcwg@ietf.org >> Objet : [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 >>=20 >> Hi all, >>=20 >> This draft is a result of the discussion we had during last meeting = in >> Orlando. We have very productive discussion about IPv4 hosts >> configuration in IPv6-only network. After we reached what looked like = a >> consensus in the meeting room, couple folks volunteered to write down >> the draft that summarizes that perceived consensus. This draft is a >> product of this effort. >>=20 >> As requested by authors, we are announcing adotion call on >> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated = to >> confirm whether there is WG consensus to adopt this work as DHC WG >> draft. Please state whether or not you're in favor of the adoption by >> replying to this mail. If you are not in favor, please also state = your >> objections in your response. This adoption call will complete on = 2013-04- >> 17. >>=20 >> Regards, >> Bernie & Tomek >>=20 >> On 03.04.2013 19:20, Marcin Siodelski wrote: >>> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am = asking >>> for adoption of this document by DHC WG. >>>=20 >>> The latest version (-01) is available here: >>>=20 >>> = http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6- >> 01.txt >>> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 >>>=20 >>> This document describes a mechanism whereby IPv4 client obtains its >>> configuration from the DHCPv4 server separated from the client by = IPv6- >>> only network having DHCPv6 service. This mechanism is frequently >>> referred as "DHCPv4-over-DHCPv6". >>>=20 >>> The DHCPv4 client's request is carried in the newly defined DHCPv6 >>> messages/option to/from the server and can be sent either through a >>> relay or directly. >>>=20 >>> Cheers, >>> Marcin >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Mon Apr 15 00:40:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209B721F92FC; Mon, 15 Apr 2013 00:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlYjV2fGpTCS; Mon, 15 Apr 2013 00:40:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2208421F92E9; Mon, 15 Apr 2013 00:40:13 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 42B4118C15B; Mon, 15 Apr 2013 09:40:13 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 216B823806B; Mon, 15 Apr 2013 09:40:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 15 Apr 2013 09:40:13 +0200 From: To: Qi Sun Date: Mon, 15 Apr 2013 09:40:12 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac45nfkOYIUUc8W6T/eYet/pmtejHwADQwkg Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> In-Reply-To: <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "dhcwg@ietf.org" , "Softwires \(softwires@ietf.org\)" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 07:40:15 -0000 UmUtLA0KDQpFeGNlcHQgIklQdjQgYWRkcmVzc2luZyItcmVsYXRlZCBjb25maWd1cmF0aW9uLCB3 aGF0IGFkZGl0aW9uYWwgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGNhbiBiZSBwcm92aXNpb25l ZCB3aXRoIERIQ1B2NCBhbmQgbm90IHdpdGggREhDUHY2PyANCldoeSBpbiB0aGUgZnV0dXJlLCBh biBJUHY2LWVuYWJsZWQgbm9kZSB3aWxsIHJlcXVpcmUgdG8gcmV0cmlldmUgY29uZmlndXJhdGlv biB1c2luZyBESENQdjQtb3Zlci1ESENQdjYgYW5kIG5vdCBkaXJlY3RseSB1c2luZyBESENQdjY/ DQoNCkNoZWVycywNCk1lZA0KDQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDog UWkgU3VuIFttYWlsdG86c3VucWkudGh1QGdtYWlsLmNvbV0NCj5FbnZvecOpwqA6IGx1bmRpIDE1 IGF2cmlsIDIwMTMgMDc6NTYNCj7DgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTg0KPkNj wqA6IFRvbWVrIE1ydWdhbHNraTsgZGhjd2dAaWV0Zi5vcmc7IFNvZnR3aXJlcyAoc29mdHdpcmVz QGlldGYub3JnKQ0KPk9iamV0wqA6IFJlOiBbZGhjd2ddIEFkb3B0aW9uIGNhbGwgb24gZHJhZnQt c2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ng0KPg0KPg0KPkRlYXIgTWVkLA0KPg0KPlRoYW5r cyBmb3IgeW91ciByZXNwb25zZS4gSGVyZSBpcyBteSB1bmRlcnN0YW5kaW5nLg0KPg0KPklNSE8s IGRlZmluaW5nIG9wdGlvbnMgaW4gREhDUHY2IHNlZW1zIHRvIGludHJvZHVjZSBsZXNzIGNvbXBs ZXhpdHkgaW4NCj5wcm90b2NvbC4gSG93ZXZlciwgd2UgZG8gbm90IGtub3cgZm9yIG5vdyB3aGlj aCBvcHRpb25zIGFyZSBuZWVkZWQgaW4gdGhlDQo+ZnV0dXJlLiBJZiB3ZSBoYXZlIHRvIHBvcnQg REhDUHY0IG9wdGlvbnMgaW50byBESENQdjYsIGhvdyBtYW55IHRpbWVzDQo+c2hvdWxkIHdlIGRv IHRoZSB3b3JrPyBMaWtlIG9uZSBuZXcgb3B0aW9uIHBlciAyIHllYXJzLCBvciByZWRlZmluaW5n IGFsbA0KPkRIQ1B2NCBvcHRpb25zIGludG8gREhDUHY2IGF0IG9uZSB0aW1lPyBUaGUgcHJvcG9z ZWQgc29sdXRpb24gdHJpZXMgdG8NCj5hdm9pZCBwb2xsdXRpbmcgdGhlIERIQ1B2NiBvcHRpb24g c3BhY2UsIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgdHJhbnNpdGlvbg0KPmluIERIQ1AuDQo+DQo+ QW5vdGhlciBwb2ludCBpcyB0aGF0LCBkZWZpbmluZyBvcHRpb24ocykgLyBjb250YWluZXIgd291 bGQgcmVxdWlyZSB0aGUNCj5ESENQdjYgZW5naW5lIHRvIGhhbmRsZSBESENQdjQgb3B0aW9ucywg d2hpY2ggd291bGQgaW50cm9kdWNlIG1vcmUNCj5jb21wbGV4aXR5IHRvIHRoZSBsb2dpYyBhbmQg aW1wbGVtZW50YXRpb24gb2YgZW5kIHBvaW50cy4gVGhlIHByb3Bvc2VkDQo+c29sdXRpb24gbGV2 ZXJhZ2VzIHRoZSBESENQdjQgZW5naW5lIGZvciBESENQdjQgbWVzc2FnZXMgLyBvcHRpb25zIGFu ZA0KPkRIQ1B2NiBlbmdpbmUgZm9yIERIQ1B2NiBtZXNzYWdlcyAvIG9wdGlvbnMuIFRoZSBlbmQg cG9pbnRzIHdvdWxkDQo+Y29tcGF0aWJsZSB0byBib3RoIERIQ1B2NCBwcm9jZXNzIGFuZCBESENQ djYgcHJvY2Vzcy4gVGhpcyBpcyBtb3JlIHN1aXRhYmxlDQo+Zm9yIHRoZSB0cmFuc2l0aW9uLg0K Pg0KPkEgdGhpcmQgY29uc2lkZXJhdGlvbiBpcywgaW4gdGhlIGNhc2Ugb2YgSVB2NiB0cmFuc2l0 aW9uLCB0aGUgREhDUCBjbGllbnQNCj4ob24gdGhlIHR1bm5lbCBlbmRwb2ludCkgaXMgYm91bmQg dG8gYmUgbW9kaWZpZWQuIFdlIHRoaW5rIGl0IGJldHRlciB0bw0KPm1vZGlmeSB0aGUgY2xpZW50 IGNvbXBsZXRlbHkgZm9yIHRoZSB0cmFuc2l0aW9uIHB1cnBvc2UuDQo+DQo+TGFzdCBidXQgbm90 IHRoZSBsZWFzdCwgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGJhc2VkIG9uIHRoZSBESENQdjYN Cj5pbmZyYXN0cnVjdHVyZSwgd2hpY2ggaGFzIGJlZW4gZGVwbG95ZWQgaW4gb3BlcmF0b3JzJyBu ZXR3b3Jrcy4NCj4NCj5UaGUgREhDUHY0IG92ZXIgREhDUHY2IG1lY2hhbmlzbSBpcyBhbiBhcmNo aXRlY3R1cmFsIGRldmVsb3BtZW50IGZvciBESENQDQo+cHJvdG9jb2wgdG8gbWVldCB0aGUgcmVx dWlyZW1lbnRzIGZvciBjb25maWd1cmluZyBJUHY0IHBhcmFtZXRlcnMgYWNyb3NzDQo+dGhlIElQ djYgbmV0d29yay4gV2UgdGhpbmsgaXQgaXMgaW1wb3J0YW50IGZvciB0aGUgREhDIFdHIHRvIHdv cmsgb24gaXQuDQo+DQo+QmVzdCBSZWdhcmRzLA0KPlFpIFN1bg0KPihTb3JyeSBmb3IgcmVzZW5k aW5nLCB0cnkgdG8gc3luY2hyb25pemUgd2l0aCBzb2Z0d2lyZSBNTC4uLikNCj4NCj5PbiAyMDEz LTQtMTIsIGF0IOS4i+WNiDc6NDcsIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPjxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4NCj4+IERlYXIgYWxsLA0KPj4N Cj4+IChJIGNjIHNvZnd0aXJlIGFzIHRoaXMgd29yayBpcyBhbHNvIHJlbGV2YW50IGZvciB0aGUg d29ya2luZyBncm91cC4pDQo+Pg0KPj4gSSBkbyBub3Qgc3VwcG9ydCB0aGlzIHdvcmsgYXMgaXQg aW5kdWNlcyBtb3JlIGNvbXBsZXhpdHkgY29tcGFyZWQgdG8ganVzdA0KPmRlZmluaW5nIGFkZXF1 YXRlIG9wdGlvbiBpbiBkaGNwdjYuIERlZmluaW5nIG9uZSBjb250YWluZXIgb3IgZmV3IERIQ1B2 Ng0KPm9wdGlvbnMgaXMgbXVjaCBtb3JlIHNpbXBsZXIgdGhhdCB0aGUgcHJvcG9zZWQgYXBwcm9h Y2guDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gTWVkDQo+Pg0KPj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPj4+IERlIDogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQNCj5kZQ0KPj4+IFRvbWVrIE1ydWdhbHNraQ0KPj4+ IEVudm95w6kgOiBtZXJjcmVkaSAzIGF2cmlsIDIwMTMgMTk6NDENCj4+PiDDgCA6IGRoY3dnQGll dGYub3JnDQo+Pj4gT2JqZXQgOiBbZGhjd2ddIEFkb3B0aW9uIGNhbGwgb24gZHJhZnQtc2Nza2Yt ZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ng0KPj4+DQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4gVGhpcyBk cmFmdCBpcyBhIHJlc3VsdCBvZiB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgZHVyaW5nIGxhc3QgbWVl dGluZyBpbg0KPj4+IE9ybGFuZG8uIFdlIGhhdmUgdmVyeSBwcm9kdWN0aXZlIGRpc2N1c3Npb24g YWJvdXQgSVB2NCBob3N0cw0KPj4+IGNvbmZpZ3VyYXRpb24gaW4gSVB2Ni1vbmx5IG5ldHdvcmsu IEFmdGVyIHdlIHJlYWNoZWQgd2hhdCBsb29rZWQgbGlrZSBhDQo+Pj4gY29uc2Vuc3VzIGluIHRo ZSBtZWV0aW5nIHJvb20sIGNvdXBsZSBmb2xrcyB2b2x1bnRlZXJlZCB0byB3cml0ZSBkb3duDQo+ Pj4gdGhlIGRyYWZ0IHRoYXQgc3VtbWFyaXplcyB0aGF0IHBlcmNlaXZlZCBjb25zZW5zdXMuIFRo aXMgZHJhZnQgaXMgYQ0KPj4+IHByb2R1Y3Qgb2YgdGhpcyBlZmZvcnQuDQo+Pj4NCj4+PiBBcyBy ZXF1ZXN0ZWQgYnkgYXV0aG9ycywgd2UgYXJlIGFubm91bmNpbmcgYWRvdGlvbiBjYWxsIG9uDQo+ Pj4gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMS4gVGhpcyBjYWxsIGlzIGJl aW5nIGluaXRpYXRlZCB0bw0KPj4+IGNvbmZpcm0gd2hldGhlciB0aGVyZSBpcyBXRyBjb25zZW5z dXMgdG8gYWRvcHQgdGhpcyB3b3JrIGFzIERIQyBXRw0KPj4+IGRyYWZ0LiBQbGVhc2Ugc3RhdGUg d2hldGhlciBvciBub3QgeW91J3JlIGluIGZhdm9yIG9mIHRoZSBhZG9wdGlvbiBieQ0KPj4+IHJl cGx5aW5nIHRvIHRoaXMgbWFpbC4gSWYgeW91IGFyZSBub3QgaW4gZmF2b3IsIHBsZWFzZSBhbHNv IHN0YXRlIHlvdXINCj4+PiBvYmplY3Rpb25zIGluIHlvdXIgcmVzcG9uc2UuIFRoaXMgYWRvcHRp b24gY2FsbCB3aWxsIGNvbXBsZXRlIG9uIDIwMTMtDQo+MDQtDQo+Pj4gMTcuDQo+Pj4NCj4+PiBS ZWdhcmRzLA0KPj4+IEJlcm5pZSAmIFRvbWVrDQo+Pj4NCj4+PiBPbiAwMy4wNC4yMDEzIDE5OjIw LCBNYXJjaW4gU2lvZGVsc2tpIHdyb3RlOg0KPj4+PiBJbiB0aGUgbmFtZSBvZiBhdXRob3JzIG9m IGRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYgSSBhbQ0KPmFza2luZw0KPj4+PiBm b3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBieSBESEMgV0cuDQo+Pj4+DQo+Pj4+IFRoZSBs YXRlc3QgdmVyc2lvbiAoLTAxKSBpcyBhdmFpbGFibGUgaGVyZToNCj4+Pj4NCj4+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVy LWRoY3B2Ni0NCj4+PiAwMS50eHQNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMQ0KPj4+Pg0KPj4+PiBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB3aGVyZWJ5IElQdjQgY2xpZW50IG9idGFpbnMgaXRz DQo+Pj4+IGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgREhDUHY0IHNlcnZlciBzZXBhcmF0ZWQgZnJv bSB0aGUgY2xpZW50IGJ5IElQdjYtDQo+Pj4+IG9ubHkgbmV0d29yayBoYXZpbmcgREhDUHY2IHNl cnZpY2UuIFRoaXMgbWVjaGFuaXNtIGlzIGZyZXF1ZW50bHkNCj4+Pj4gcmVmZXJyZWQgYXMgIkRI Q1B2NC1vdmVyLURIQ1B2NiIuDQo+Pj4+DQo+Pj4+IFRoZSBESENQdjQgY2xpZW50J3MgcmVxdWVz dCBpcyBjYXJyaWVkIGluIHRoZSBuZXdseSBkZWZpbmVkIERIQ1B2Ng0KPj4+PiBtZXNzYWdlcy9v cHRpb24gdG8vZnJvbSB0aGUgc2VydmVyIGFuZCBjYW4gYmUgc2VudCBlaXRoZXIgdGhyb3VnaCBh DQo+Pj4+IHJlbGF5IG9yIGRpcmVjdGx5Lg0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IE1hcmNp bg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4+Pj4gZGhjd2dAaWV0 Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K Pj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+PiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4+PiBkaGN3Z0BpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBkaGN3ZyBtYWlsaW5nIGxp c3QNCj4+IGRoY3dnQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnDQoNCg== From sunqi.csnet.thu@gmail.com Mon Apr 15 01:59:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0521F934A; Mon, 15 Apr 2013 01:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykCqhTvhHMC5; Mon, 15 Apr 2013 01:59:48 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD721F9347; Mon, 15 Apr 2013 01:59:47 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id f4so4234001oah.14 for ; Mon, 15 Apr 2013 01:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dgbm1WXazrD+bA7hl/Zt4N3qRmEBAMbr7ekkaICCJDE=; b=r9cjQkv8kAksQE9c7cR6UruzvqTiOsseVCyn7bwpupSDQ6A34v+pu7TfYwvjrIuzDU tmlcH0tiUFCcT3m6+htfJyFrsqDnIh+wS4922ORU5JYLxdKkSCTOMEMWxxXadtZH78wM orAiKWJtKD9K+9DHkrweSfPRWv49Yo1TZ8r9MtO3DtObCsnsm8HDpQtaE913QVcZccpk zlkBDeFH2mSWpjM1+OILxfTVk998Fdi1EPB1V6GggN9vEld7I0XHh9qYH4rvG6f45e4N go77jRnp7VBsHAHvgxi7iRXT1kH52Et50rIxQQew1UPYnHa6M9o1E1K+CRgsKRdulxvR SxaQ== MIME-Version: 1.0 X-Received: by 10.182.49.102 with SMTP id t6mr7095536obn.75.1366016387407; Mon, 15 Apr 2013 01:59:47 -0700 (PDT) Received: by 10.60.97.35 with HTTP; Mon, 15 Apr 2013 01:59:47 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 15 Apr 2013 16:59:47 +0800 Message-ID: From: Qi Sun To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f46d04479f778766ad04da6279fe Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 08:59:49 -0000 --f46d04479f778766ad04da6279fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Med, Please see inline. Except "IPv4 addressing"-related configuration, what additional > configuration parameters can be provisioned with DHCPv4 and not with DHCP= v6? > [Qi] There are over 200 DHCPv4 options that may be required to provide IPv4 services. In the period of transition, some service providers and services may remain in IPv4 for some time, while end users may demand these IPv4 services to be delivered over IPv6. The required info may be more than IPv4 addresses (port set). As for examples, IMHO, SIP server option and NTP server option are potential customers for this usage. There may be more, because demands are arising with time going on. > Why in the future, an IPv6-enabled node will require to retrieve > configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6? > > [Qi] We are talking about IPv6-enabled node in IPv4/IPv6 transition period, when IPv4 and IPv6 services are coexisted. Using DHCPv4-over-DHCPv6 can guarantee all DHCP-based services to be configured correctly. Of course, in IPv6 only Internet where there is no demand for IPv4 services, we should use DHCPv6. But DHCPv4-over-DHCPv6 can also work in this case. Best Regards, Qi > Cheers, > Med > > >-----Message d'origine----- > >De : Qi Sun [mailto:sunqi.thu@gmail.com] > >Envoy=C3=A9 : lundi 15 avril 2013 07:56 > >=C3=80 : BOUCADAIR Mohamed OLNC/OLN > >Cc : Tomek Mrugalski; dhcwg@ietf.org; Softwires (softwires@ietf.org) > >Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > > > > > >Dear Med, > > > >Thanks for your response. Here is my understanding. > > > >IMHO, defining options in DHCPv6 seems to introduce less complexity in > >protocol. However, we do not know for now which options are needed in th= e > >future. If we have to port DHCPv4 options into DHCPv6, how many times > >should we do the work? Like one new option per 2 years, or redefining al= l > >DHCPv4 options into DHCPv6 at one time? The proposed solution tries to > >avoid polluting the DHCPv6 option space, which is necessary for transiti= on > >in DHCP. > > > >Another point is that, defining option(s) / container would require the > >DHCPv6 engine to handle DHCPv4 options, which would introduce more > >complexity to the logic and implementation of end points. The proposed > >solution leverages the DHCPv4 engine for DHCPv4 messages / options and > >DHCPv6 engine for DHCPv6 messages / options. The end points would > >compatible to both DHCPv4 process and DHCPv6 process. This is more > suitable > >for the transition. > > > >A third consideration is, in the case of IPv6 transition, the DHCP clien= t > >(on the tunnel endpoint) is bound to be modified. We think it better to > >modify the client completely for the transition purpose. > > > >Last but not the least, the proposed solution is based on the DHCPv6 > >infrastructure, which has been deployed in operators' networks. > > > >The DHCPv4 over DHCPv6 mechanism is an architectural development for DHC= P > >protocol to meet the requirements for configuring IPv4 parameters across > >the IPv6 network. We think it is important for the DHC WG to work on it. > > > >Best Regards, > >Qi Sun > >(Sorry for resending, try to synchronize with softwire ML...) > > > >On 2013-4-12, at =E4=B8=8B=E5=8D=887:47, > > wrote: > > > >> Dear all, > >> > >> (I cc sofwtire as this work is also relevant for the working group.) > >> > >> I do not support this work as it induces more complexity compared to > just > >defining adequate option in dhcpv6. Defining one container or few DHCPv6 > >options is much more simpler that the proposed approach. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la par= t > >de > >>> Tomek Mrugalski > >>> Envoy=C3=A9 : mercredi 3 avril 2013 19:41 > >>> =C3=80 : dhcwg@ietf.org > >>> Objet : [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > >>> > >>> Hi all, > >>> > >>> This draft is a result of the discussion we had during last meeting i= n > >>> Orlando. We have very productive discussion about IPv4 hosts > >>> configuration in IPv6-only network. After we reached what looked like= a > >>> consensus in the meeting room, couple folks volunteered to write down > >>> the draft that summarizes that perceived consensus. This draft is a > >>> product of this effort. > >>> > >>> As requested by authors, we are announcing adotion call on > >>> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated t= o > >>> confirm whether there is WG consensus to adopt this work as DHC WG > >>> draft. Please state whether or not you're in favor of the adoption by > >>> replying to this mail. If you are not in favor, please also state you= r > >>> objections in your response. This adoption call will complete on 2013= - > >04- > >>> 17. > >>> > >>> Regards, > >>> Bernie & Tomek > >>> > >>> On 03.04.2013 19:20, Marcin Siodelski wrote: > >>>> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am > >asking > >>>> for adoption of this document by DHC WG. > >>>> > >>>> The latest version (-01) is available here: > >>>> > >>>> > http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6- > >>> 01.txt > >>>> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 > >>>> > >>>> This document describes a mechanism whereby IPv4 client obtains its > >>>> configuration from the DHCPv4 server separated from the client by > IPv6- > >>>> only network having DHCPv6 service. This mechanism is frequently > >>>> referred as "DHCPv4-over-DHCPv6". > >>>> > >>>> The DHCPv4 client's request is carried in the newly defined DHCPv6 > >>>> messages/option to/from the server and can be sent either through a > >>>> relay or directly. > >>>> > >>>> Cheers, > >>>> Marcin > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> dhcwg mailing list > >>>> dhcwg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dhcwg > >>>> > >>> > >>> _______________________________________________ > >>> dhcwg mailing list > >>> dhcwg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dhcwg > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --f46d04479f778766ad04da6279fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Med,

Please see inline.

Except "IPv4 addressing"-related configuration, what additional c= onfiguration parameters can be provisioned with DHCPv4 and not with DHCPv6?=

[Qi] There are over 200 DHCPv4 o= ptions that may be required to provide IPv4 services. In the period of tran= sition, some service providers and services may remain in IPv4 for some tim= e, while end users may demand these IPv4 services to be delivered over IPv6= . The required info may be more than IPv4 addresses (port set). As for exam= ples, IMHO, SIP server option and NTP server option are potential customers= for this usage. There may be more, because demands are arising with time g= oing on.=C2=A0
=C2=A0
Why in the future, an IPv6-enabled node will require to retrieve configurat= ion using DHCPv4-over-DHCPv6 and not directly using DHCPv6?

[Qi] We are talking abo= ut IPv6-enabled node in IPv4/IPv6 transition period, when IPv4 and IPv6 ser= vices are coexisted. Using DHCPv4-over-DHCPv6 can guarantee all DHCP-based = services to be configured correctly.

Of course, in IPv6 only Internet where ther= e is no demand for IPv4 services, we should use DHCPv6. But DHCPv4-over-DHC= Pv6 can also work in this case.

Best R= egards,
Qi
=C2=A0
Cheers,
Med

>-----Message d'origine-----
>De=C2=A0: Qi Sun [mailto:s= unqi.thu@gmail.com]
>Envoy=C3=A9=C2=A0: lundi 15 avril 2013 07:56
>=C3=80=C2=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=C2=A0: Tomek Mrugalski; dhcwg@ietf= .org; Softwires (softwires@ietf.o= rg)
>Objet=C2=A0: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-d= hcpv6
>
>
>Dear Med,
>
>Thanks for your response. Here is my understanding.
>
>IMHO, defining options in DHCPv6 seems to introduce less complexity in<= br> >protocol. However, we do not know for now which options are needed in t= he
>future. If we have to port DHCPv4 options into DHCPv6, how many times >should we do the work? Like one new option per 2 years, or redefining a= ll
>DHCPv4 options into DHCPv6 at one time? The proposed solution tries to<= br> >avoid polluting the DHCPv6 option space, which is necessary for transit= ion
>in DHCP.
>
>Another point is that, defining option(s) / container would require the=
>DHCPv6 engine to handle DHCPv4 options, which would introduce more
>complexity to the logic and implementation of end points. The proposed<= br> >solution leverages the DHCPv4 engine for DHCPv4 messages / options and<= br> >DHCPv6 engine for DHCPv6 messages / options. The end points would
>compatible to both DHCPv4 process and DHCPv6 process. This is more suit= able
>for the transition.
>
>A third consideration is, in the case of IPv6 transition, the DHCP clie= nt
>(on the tunnel endpoint) is bound to be modified. We think it better to=
>modify the client completely for the transition purpose.
>
>Last but not the least, the proposed solution is based on the DHCPv6 >infrastructure, which has been deployed in operators' networks.
>
>The DHCPv4 over DHCPv6 mechanism is an architectural development for DH= CP
>protocol to meet the requirements for configuring IPv4 parameters acros= s
>the IPv6 network. We think it is important for the DHC WG to work on it= .
>
>Best Regards,
>Qi Sun
>(Sorry for resending, try to synchronize with softwire ML...)
>
>On 2013-4-12, at =E4=B8=8B=E5=8D=887:47, <mohamed.boucadair@orange.com>
><mohamed.boucadair@o= range.com> wrote:
>
>> Dear all,
>>
>> (I cc sofwtire as this work is also relevant for the working group= .)
>>
>> I do not support this work as it induces more complexity compared = to just
>defining adequate option in dhcpv6. Defining one container or few DHCPv= 6
>options is much more simpler that the proposed approach.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : dhcwg-bounces@i= etf.org [mailto:dhcwg-bounces= @ietf.org] De la part
>de
>>> Tomek Mrugalski
>>> Envoy=C3=A9 : mercredi 3 avril 2013 19:41
>>> =C3=80 : dhcwg@ietf.org<= br> >>> Objet : [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-d= hcpv6
>>>
>>> Hi all,
>>>
>>> This draft is a result of the discussion we had during last me= eting in
>>> Orlando. We have very productive discussion about IPv4 hosts >>> configuration in IPv6-only network. After we reached what look= ed like a
>>> consensus in the meeting room, couple folks volunteered to wri= te down
>>> the draft that summarizes that perceived consensus. This draft= is a
>>> product of this effort.
>>>
>>> As requested by authors, we are announcing adotion call on
>>> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being init= iated to
>>> confirm whether there is WG consensus to adopt this work as DH= C WG
>>> draft. Please state whether or not you're in favor of the = adoption by
>>> replying to this mail. If you are not in favor, please also st= ate your
>>> objections in your response. This adoption call will complete = on 2013-
>04-
>>> 17.
>>>
>>> Regards,
>>> Bernie & Tomek
>>>
>>> On 03.04.2013 19:20, Marcin Siodelski wrote:
>>>> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcp= v6 I am
>asking
>>>> for adoption of this document by DHC WG.
>>>>
>>>> The latest version (-01) is available here:
>>>>
>>>> http://www.ietf.org/internet-dr= afts/draft-scskf-dhc-dhcpv4-over-dhcpv6-
>>> 01.txt
>>>> http://tools.ietf.org/html/draft-scskf= -dhc-dhcpv4-over-dhcpv6-01
>>>>
>>>> This document describes a mechanism whereby IPv4 client ob= tains its
>>>> configuration from the DHCPv4 server separated from the cl= ient by IPv6-
>>>> only network having DHCPv6 service. This mechanism is freq= uently
>>>> referred as "DHCPv4-over-DHCPv6".
>>>>
>>>> The DHCPv4 client's request is carried in the newly de= fined DHCPv6
>>>> messages/option to/from the server and can be sent either = through a
>>>> relay or directly.
>>>>
>>>> Cheers,
>>>> Marcin
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>>
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg

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

--f46d04479f778766ad04da6279fe-- From mohamed.boucadair@orange.com Mon Apr 15 02:35:30 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B121F9357; Mon, 15 Apr 2013 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRV+xK4HDFhB; Mon, 15 Apr 2013 02:35:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC121F9356; Mon, 15 Apr 2013 02:35:28 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id DFB972DC4D1; Mon, 15 Apr 2013 11:35:27 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C1B124C024; Mon, 15 Apr 2013 11:35:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 15 Apr 2013 11:35:27 +0200 From: To: Qi Sun Date: Mon, 15 Apr 2013 11:35:27 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac45t5by2RCTvlXUQjeCLBzBsTG2gQAA4B7w Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EC2D7C478PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.15.85715 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:35:30 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EC2D7C478PUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogUWkgU3Vu IFttYWlsdG86c3VucWkuY3NuZXQudGh1QGdtYWlsLmNvbV0NCkVudm95w6kgOiBsdW5kaSAxNSBh dnJpbCAyMDEzIDExOjAwDQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQpDYyA6IGRo Y3dnQGlldGYub3JnOyBTb2Z0d2lyZXMgKHNvZnR3aXJlc0BpZXRmLm9yZykNCk9iamV0IDogUmU6 IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhj cHY2DQoNCkRlYXIgTWVkLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KRXhjZXB0ICJJUHY0IGFk ZHJlc3NpbmciLXJlbGF0ZWQgY29uZmlndXJhdGlvbiwgd2hhdCBhZGRpdGlvbmFsIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVycyBjYW4gYmUgcHJvdmlzaW9uZWQgd2l0aCBESENQdjQgYW5kIG5vdCB3 aXRoIERIQ1B2Nj8NCg0KW1FpXSBUaGVyZSBhcmUgb3ZlciAyMDAgREhDUHY0IG9wdGlvbnMgdGhh dCBtYXkgYmUgcmVxdWlyZWQgdG8gcHJvdmlkZSBJUHY0IHNlcnZpY2VzLiBJbiB0aGUgcGVyaW9k IG9mIHRyYW5zaXRpb24sDQpbTWVkXSBUaGUgcXVlc3Rpb24gaXMgbm90IGhvdyBtYW55IGRoY3B2 NCBleGlzdCwgYnV0IHdoaWNoIG9uZXMgYXJlIHJlYWxseSBuZWVkZWQgd2hlbiB0aGUgaG9zdCBp cyBJUHY2LWVuYWJsZWQuDQoNCg0Kc29tZSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgc2VydmljZXMg bWF5IHJlbWFpbiBpbiBJUHY0IGZvciBzb21lIHRpbWUsIHdoaWxlIGVuZCB1c2VycyBtYXkgZGVt YW5kIHRoZXNlIElQdjQgc2VydmljZXMgdG8gYmUgZGVsaXZlcmVkIG92ZXIgSVB2Ni4gVGhlIHJl cXVpcmVkIGluZm8gbWF5IGJlIG1vcmUgdGhhbiBJUHY0IGFkZHJlc3NlcyAocG9ydCBzZXQpLiBB cyBmb3IgZXhhbXBsZXMsIElNSE8sIFNJUCBzZXJ2ZXIgb3B0aW9uIGFuZA0KW01lZF0gVGhpcyBp cyBkb2FibGUgdXNpbmcgb3B0aW9uIDIxLiBUaGUgbmFtZSBjYW4gYmUgcmVzb2x2ZWQgdG8gYW4g SVB2NiBvciBhbiBJUHY0IGFkZHJlc3MuIE5vdGhpbmcgcHJldmVudCBmcm9tIGRvaW5nIHNvLg0K DQpOVFAgc2VydmVyIG9wdGlvbiBhcmUgcG90ZW50aWFsIGN1c3RvbWVycyBmb3IgdGhpcyB1c2Fn ZS4NCltNZWRdIFRoaXMgaXMgZG9hYmxlIHVzaW5nIGRoY3B2Ni4gV2h5IHRoZSB1c2UgZGhwdjQt b3Zlci1kaGNwdjYgaXMgYSBtdXN0Pw0KDQpUaGVyZSBtYXkgYmUgbW9yZSwgYmVjYXVzZSBkZW1h bmRzIGFyZSBhcmlzaW5nIHdpdGggdGltZSBnb2luZyBvbi4NCltNZWRdIEnigJltIHN0aWxsIG5v dCBzZWVpbmcgYW55IHBhcnRpY3VsYXIgZGVtYW5kIHdoaWNoIGNhbm5vdCBiZSBob25vcmVkIHVz aW5nIGRoY3B2Ni4NCg0KDQpXaHkgaW4gdGhlIGZ1dHVyZSwgYW4gSVB2Ni1lbmFibGVkIG5vZGUg d2lsbCByZXF1aXJlIHRvIHJldHJpZXZlIGNvbmZpZ3VyYXRpb24gdXNpbmcgREhDUHY0LW92ZXIt REhDUHY2IGFuZCBub3QgZGlyZWN0bHkgdXNpbmcgREhDUHY2Pw0KDQpbUWldIFdlIGFyZSB0YWxr aW5nIGFib3V0IElQdjYtZW5hYmxlZCBub2RlIGluIElQdjQvSVB2NiB0cmFuc2l0aW9uIHBlcmlv ZCwgd2hlbiBJUHY0IGFuZCBJUHY2IHNlcnZpY2VzIGFyZSBjb2V4aXN0ZWQuIFVzaW5nIERIQ1B2 NC1vdmVyLURIQ1B2NiBjYW4gZ3VhcmFudGVlIGFsbCBESENQLWJhc2VkIHNlcnZpY2VzIHRvIGJl IGNvbmZpZ3VyZWQgY29ycmVjdGx5Lg0KDQpbTWVkXSBXaGF0IGFyZSB0aG9zZSBzZXJ2aWNlcz8g V2h5IHRob3NlIHNlcnZpY2VzIGNhbm5vdCBiZSBjb25maWd1cmVkIHVzaW5nIERIQ1B2Nj8gQmVm b3JlIGRlc2lnbmluZyBhIHNvbHV0aW9uLCB3ZSBuZWVkIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVt ZW50cyBhbmQgdGhlIG5lZWRzIGZpcnN0Lg0KDQpPZiBjb3Vyc2UsIGluIElQdjYgb25seSBJbnRl cm5ldCB3aGVyZSB0aGVyZSBpcyBubyBkZW1hbmQgZm9yIElQdjQgc2VydmljZXMsIHdlIHNob3Vs ZCB1c2UgREhDUHY2LiBCdXQgREhDUHY0LW92ZXItREhDUHY2IGNhbiBhbHNvIHdvcmsgaW4gdGhp cyBjYXNlLg0KDQpbTWVkXSDigKYgZXhjZXB0IHRoYXQgZGhjcHY0LW92ZXItZGhjcHY2IGludHJv ZHVjZXMgbW9yZSBjb21wbGV4aXR5IGZvciBub3Qgb2J2aW91cyByZWFzb25zLg0KDQpCZXN0IFJl Z2FyZHMsDQpRaQ0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPkRlIDogUWkgU3VuIFttYWlsdG86c3VucWkudGh1QGdtYWlsLmNvbTxtYWlsdG86c3VucWku dGh1QGdtYWlsLmNvbT5dDQo+RW52b3nDqSA6IGx1bmRpIDE1IGF2cmlsIDIwMTMgMDc6NTYNCj7D gCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Q2MgOiBUb21layBNcnVnYWxza2k7IGRo Y3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz47IFNvZnR3aXJlcyAoc29mdHdpcmVz QGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+KQ0KPk9iamV0IDogUmU6IFtkaGN3 Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2DQo+ DQo+DQo+RGVhciBNZWQsDQo+DQo+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBIZXJlIGlzIG15 IHVuZGVyc3RhbmRpbmcuDQo+DQo+SU1ITywgZGVmaW5pbmcgb3B0aW9ucyBpbiBESENQdjYgc2Vl bXMgdG8gaW50cm9kdWNlIGxlc3MgY29tcGxleGl0eSBpbg0KPnByb3RvY29sLiBIb3dldmVyLCB3 ZSBkbyBub3Qga25vdyBmb3Igbm93IHdoaWNoIG9wdGlvbnMgYXJlIG5lZWRlZCBpbiB0aGUNCj5m dXR1cmUuIElmIHdlIGhhdmUgdG8gcG9ydCBESENQdjQgb3B0aW9ucyBpbnRvIERIQ1B2NiwgaG93 IG1hbnkgdGltZXMNCj5zaG91bGQgd2UgZG8gdGhlIHdvcms/IExpa2Ugb25lIG5ldyBvcHRpb24g cGVyIDIgeWVhcnMsIG9yIHJlZGVmaW5pbmcgYWxsDQo+REhDUHY0IG9wdGlvbnMgaW50byBESENQ djYgYXQgb25lIHRpbWU/IFRoZSBwcm9wb3NlZCBzb2x1dGlvbiB0cmllcyB0bw0KPmF2b2lkIHBv bGx1dGluZyB0aGUgREhDUHY2IG9wdGlvbiBzcGFjZSwgd2hpY2ggaXMgbmVjZXNzYXJ5IGZvciB0 cmFuc2l0aW9uDQo+aW4gREhDUC4NCj4NCj5Bbm90aGVyIHBvaW50IGlzIHRoYXQsIGRlZmluaW5n IG9wdGlvbihzKSAvIGNvbnRhaW5lciB3b3VsZCByZXF1aXJlIHRoZQ0KPkRIQ1B2NiBlbmdpbmUg dG8gaGFuZGxlIERIQ1B2NCBvcHRpb25zLCB3aGljaCB3b3VsZCBpbnRyb2R1Y2UgbW9yZQ0KPmNv bXBsZXhpdHkgdG8gdGhlIGxvZ2ljIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBlbmQgcG9pbnRzLiBU aGUgcHJvcG9zZWQNCj5zb2x1dGlvbiBsZXZlcmFnZXMgdGhlIERIQ1B2NCBlbmdpbmUgZm9yIERI Q1B2NCBtZXNzYWdlcyAvIG9wdGlvbnMgYW5kDQo+REhDUHY2IGVuZ2luZSBmb3IgREhDUHY2IG1l c3NhZ2VzIC8gb3B0aW9ucy4gVGhlIGVuZCBwb2ludHMgd291bGQNCj5jb21wYXRpYmxlIHRvIGJv dGggREhDUHY0IHByb2Nlc3MgYW5kIERIQ1B2NiBwcm9jZXNzLiBUaGlzIGlzIG1vcmUgc3VpdGFi bGUNCj5mb3IgdGhlIHRyYW5zaXRpb24uDQo+DQo+QSB0aGlyZCBjb25zaWRlcmF0aW9uIGlzLCBp biB0aGUgY2FzZSBvZiBJUHY2IHRyYW5zaXRpb24sIHRoZSBESENQIGNsaWVudA0KPihvbiB0aGUg dHVubmVsIGVuZHBvaW50KSBpcyBib3VuZCB0byBiZSBtb2RpZmllZC4gV2UgdGhpbmsgaXQgYmV0 dGVyIHRvDQo+bW9kaWZ5IHRoZSBjbGllbnQgY29tcGxldGVseSBmb3IgdGhlIHRyYW5zaXRpb24g cHVycG9zZS4NCj4NCj5MYXN0IGJ1dCBub3QgdGhlIGxlYXN0LCB0aGUgcHJvcG9zZWQgc29sdXRp b24gaXMgYmFzZWQgb24gdGhlIERIQ1B2Ng0KPmluZnJhc3RydWN0dXJlLCB3aGljaCBoYXMgYmVl biBkZXBsb3llZCBpbiBvcGVyYXRvcnMnIG5ldHdvcmtzLg0KPg0KPlRoZSBESENQdjQgb3ZlciBE SENQdjYgbWVjaGFuaXNtIGlzIGFuIGFyY2hpdGVjdHVyYWwgZGV2ZWxvcG1lbnQgZm9yIERIQ1AN Cj5wcm90b2NvbCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgZm9yIGNvbmZpZ3VyaW5nIElQdjQg cGFyYW1ldGVycyBhY3Jvc3MNCj50aGUgSVB2NiBuZXR3b3JrLiBXZSB0aGluayBpdCBpcyBpbXBv cnRhbnQgZm9yIHRoZSBESEMgV0cgdG8gd29yayBvbiBpdC4NCj4NCj5CZXN0IFJlZ2FyZHMsDQo+ UWkgU3VuDQo+KFNvcnJ5IGZvciByZXNlbmRpbmcsIHRyeSB0byBzeW5jaHJvbml6ZSB3aXRoIHNv ZnR3aXJlIE1MLi4uKQ0KPg0KPk9uIDIwMTMtNC0xMiwgYXQg5LiL5Y2INzo0NywgPG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ Pg0KPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+DQo+PiBEZWFyIGFsbCwNCj4+DQo+PiAoSSBjYyBzb2Z3 dGlyZSBhcyB0aGlzIHdvcmsgaXMgYWxzbyByZWxldmFudCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAu KQ0KPj4NCj4+IEkgZG8gbm90IHN1cHBvcnQgdGhpcyB3b3JrIGFzIGl0IGluZHVjZXMgbW9yZSBj b21wbGV4aXR5IGNvbXBhcmVkIHRvIGp1c3QNCj5kZWZpbmluZyBhZGVxdWF0ZSBvcHRpb24gaW4g ZGhjcHY2LiBEZWZpbmluZyBvbmUgY29udGFpbmVyIG9yIGZldyBESENQdjYNCj5vcHRpb25zIGlz IG11Y2ggbW9yZSBzaW1wbGVyIHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNoLg0KPj4NCj4+IENo ZWVycywNCj4+IE1lZA0KPj4NCj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+PiBE ZSA6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZz5dIERlIGxhIHBhcnQNCj5kZQ0KPj4+IFRvbWVrIE1ydWdhbHNraQ0KPj4+IEVudm95w6kg OiBtZXJjcmVkaSAzIGF2cmlsIDIwMTMgMTk6NDENCj4+PiDDgCA6IGRoY3dnQGlldGYub3JnPG1h aWx0bzpkaGN3Z0BpZXRmLm9yZz4NCj4+PiBPYmpldCA6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBv biBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2DQo+Pj4NCj4+PiBIaSBhbGwsDQo+ Pj4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBk dXJpbmcgbGFzdCBtZWV0aW5nIGluDQo+Pj4gT3JsYW5kby4gV2UgaGF2ZSB2ZXJ5IHByb2R1Y3Rp dmUgZGlzY3Vzc2lvbiBhYm91dCBJUHY0IGhvc3RzDQo+Pj4gY29uZmlndXJhdGlvbiBpbiBJUHY2 LW9ubHkgbmV0d29yay4gQWZ0ZXIgd2UgcmVhY2hlZCB3aGF0IGxvb2tlZCBsaWtlIGENCj4+PiBj b25zZW5zdXMgaW4gdGhlIG1lZXRpbmcgcm9vbSwgY291cGxlIGZvbGtzIHZvbHVudGVlcmVkIHRv IHdyaXRlIGRvd24NCj4+PiB0aGUgZHJhZnQgdGhhdCBzdW1tYXJpemVzIHRoYXQgcGVyY2VpdmVk IGNvbnNlbnN1cy4gVGhpcyBkcmFmdCBpcyBhDQo+Pj4gcHJvZHVjdCBvZiB0aGlzIGVmZm9ydC4N Cj4+Pg0KPj4+IEFzIHJlcXVlc3RlZCBieSBhdXRob3JzLCB3ZSBhcmUgYW5ub3VuY2luZyBhZG90 aW9uIGNhbGwgb24NCj4+PiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxLiBU aGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvDQo+Pj4gY29uZmlybSB3aGV0aGVyIHRoZXJl IGlzIFdHIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIHdvcmsgYXMgREhDIFdHDQo+Pj4gZHJhZnQu IFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlIGFkb3B0 aW9uIGJ5DQo+Pj4gcmVwbHlpbmcgdG8gdGhpcyBtYWlsLiBJZiB5b3UgYXJlIG5vdCBpbiBmYXZv ciwgcGxlYXNlIGFsc28gc3RhdGUgeW91cg0KPj4+IG9iamVjdGlvbnMgaW4geW91ciByZXNwb25z ZS4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29tcGxldGUgb24gMjAxMy0NCj4wNC0NCj4+PiAx Ny4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4gQmVybmllICYgVG9tZWsNCj4+Pg0KPj4+IE9uIDAz LjA0LjIwMTMgMTk6MjAsIE1hcmNpbiBTaW9kZWxza2kgd3JvdGU6DQo+Pj4+IEluIHRoZSBuYW1l IG9mIGF1dGhvcnMgb2YgZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NiBJIGFtDQo+ YXNraW5nDQo+Pj4+IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGJ5IERIQyBXRy4NCj4+ Pj4NCj4+Pj4gVGhlIGxhdGVzdCB2ZXJzaW9uICgtMDEpIGlzIGF2YWlsYWJsZSBoZXJlOg0KPj4+ Pg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zY3NrZi1k aGMtZGhjcHY0LW92ZXItZGhjcHY2LQ0KPj4+IDAxLnR4dA0KPj4+PiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxDQo+Pj4+DQo+ Pj4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIHdoZXJlYnkgSVB2NCBjbGll bnQgb2J0YWlucyBpdHMNCj4+Pj4gY29uZmlndXJhdGlvbiBmcm9tIHRoZSBESENQdjQgc2VydmVy IHNlcGFyYXRlZCBmcm9tIHRoZSBjbGllbnQgYnkgSVB2Ni0NCj4+Pj4gb25seSBuZXR3b3JrIGhh dmluZyBESENQdjYgc2VydmljZS4gVGhpcyBtZWNoYW5pc20gaXMgZnJlcXVlbnRseQ0KPj4+PiBy ZWZlcnJlZCBhcyAiREhDUHY0LW92ZXItREhDUHY2Ii4NCj4+Pj4NCj4+Pj4gVGhlIERIQ1B2NCBj bGllbnQncyByZXF1ZXN0IGlzIGNhcnJpZWQgaW4gdGhlIG5ld2x5IGRlZmluZWQgREhDUHY2DQo+ Pj4+IG1lc3NhZ2VzL29wdGlvbiB0by9mcm9tIHRoZSBzZXJ2ZXIgYW5kIGNhbiBiZSBzZW50IGVp dGhlciB0aHJvdWdoIGENCj4+Pj4gcmVsYXkgb3IgZGlyZWN0bHkuDQo+Pj4+DQo+Pj4+IENoZWVy cywNCj4+Pj4gTWFyY2luDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IGRoY3dnIG1haWxpbmcgbGlzdA0K Pj4+PiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+Pj4NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZGhjd2cgbWFp bGluZyBsaXN0DQo+Pj4gZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBkaGN3ZyBtYWlsaW5n IGxpc3QNCj4+IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhj d2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQo= --_000_94C682931C08B048B7A8645303FDC9F36EC2D7C478PUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3Ro aWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUg YnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVs bGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojMUY0OTdEOw0K CWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRp b246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUZSIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6IzFGNDk3RCc+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5DaGVlcnMsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPk1lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5EZSZuYnNw Ozo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IFFpIFN1biBbbWFpbHRvOnN1bnFpLmNzbmV0LnRodUBnbWFp bC5jb21dIDxicj48Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTUgYXZyaWwgMjAxMyAxMTow MDxicj48Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xOPGJyPjxiPkNj Jm5ic3A7OjwvYj4gZGhjd2dAaWV0Zi5vcmc7IFNvZnR3aXJlcyAoc29mdHdpcmVzQGlldGYub3Jn KTxicj48Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbZGhjd2ddIEFkb3B0aW9uIGNhbGwgb24gZHJh ZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+RGVhciBNZWQsPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PHAgY2xhc3M9 TXNvTm9ybWFsPkV4Y2VwdCAmcXVvdDtJUHY0IGFkZHJlc3NpbmcmcXVvdDstcmVsYXRlZCBjb25m aWd1cmF0aW9uLCB3aGF0IGFkZGl0aW9uYWwgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGNhbiBi ZSBwcm92aXNpb25lZCB3aXRoIERIQ1B2NCBhbmQgbm90IHdpdGggREhDUHY2PzxvOnA+PC9vOnA+ PC9wPjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5bUWldIFRoZXJlIGFyZSBvdmVyIDIw MCBESENQdjQgb3B0aW9ucyB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBwcm92aWRlIElQdjQgc2Vy dmljZXMuIEluIHRoZSBwZXJpb2Qgb2YgdHJhbnNpdGlvbiwgPHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOiMxRjQ5N0QnPltNZWRdIFRoZSBxdWVzdGlvbiBpcyBub3QgaG93IG1hbnkgZGhjcHY0 IGV4aXN0LCBidXQgd2hpY2ggb25lcyBhcmUgcmVhbGx5IG5lZWRlZCB3aGVuIHRoZSBob3N0IGlz IElQdjYtZW5hYmxlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+c29tZSBzZXJ2aWNl IHByb3ZpZGVycyBhbmQgc2VydmljZXMgbWF5IHJlbWFpbiBpbiBJUHY0IGZvciBzb21lIHRpbWUs IHdoaWxlIGVuZCB1c2VycyBtYXkgZGVtYW5kIHRoZXNlIElQdjQgc2VydmljZXMgdG8gYmUgZGVs aXZlcmVkIG92ZXIgSVB2Ni4gPC9zcGFuPlRoZSByZXF1aXJlZCBpbmZvIG1heSBiZSBtb3JlIHRo YW4gSVB2NCBhZGRyZXNzZXMgKHBvcnQgc2V0KS4gQXMgZm9yIGV4YW1wbGVzLCBJTUhPLCBTSVAg c2VydmVyIG9wdGlvbiBhbmQgPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPltN ZWRdIFRoaXMgaXMgZG9hYmxlIHVzaW5nIG9wdGlvbiAyMS4gVGhlIG5hbWUgY2FuIGJlIHJlc29s dmVkIHRvIGFuIElQdjYgb3IgYW4gSVB2NCBhZGRyZXNzLiBOb3RoaW5nIHByZXZlbnQgZnJvbSBk b2luZyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+TlRQIHNlcnZlciBvcHRpb24gYXJlIHBvdGVudGlhbCBj dXN0b21lcnMgZm9yIHRoaXMgdXNhZ2UuPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+ PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjojMUY0OTdEJz5bTWVkXSBUaGlzIGlzIGRvYWJsZSB1c2luZyBkaGNwdjYuIFdoeSB0aGUgdXNl IGRocHY0LW92ZXItZGhjcHY2IGlzIGEgbXVzdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+IFRoZXJlIG1heSBi ZSBtb3JlLCBiZWNhdXNlIGRlbWFuZHMgYXJlIGFyaXNpbmcgd2l0aCB0aW1lIGdvaW5nIG9uLjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+W01lZF0gSeKAmW0gc3Rp bGwgbm90IHNlZWluZyBhbnkgcGFydGljdWxhciBkZW1hbmQgd2hpY2ggY2Fubm90IGJlIGhvbm9y ZWQgdXNpbmcgZGhjcHY2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+V2h5IGluIHRoZSBmdXR1 cmUsIGFuIElQdjYtZW5hYmxlZCBub2RlIHdpbGwgcmVxdWlyZSB0byByZXRyaWV2ZSBjb25maWd1 cmF0aW9uIHVzaW5nIERIQ1B2NC1vdmVyLURIQ1B2NiBhbmQgbm90IGRpcmVjdGx5IHVzaW5nIERI Q1B2Nj88bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+W1FpXSBX ZSBhcmUgdGFsa2luZyBhYm91dCBJUHY2LWVuYWJsZWQgbm9kZSBpbiBJUHY0L0lQdjYgdHJhbnNp dGlvbiBwZXJpb2QsIHdoZW4gSVB2NCBhbmQgSVB2NiBzZXJ2aWNlcyBhcmUgY29leGlzdGVkLiBV c2luZyBESENQdjQtb3Zlci1ESENQdjYgY2FuIGd1YXJhbnRlZSBhbGwgREhDUC1iYXNlZCBzZXJ2 aWNlcyB0byBiZSBjb25maWd1cmVkIGNvcnJlY3RseS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPltNZWRdIFdo YXQgYXJlIHRob3NlIHNlcnZpY2VzPyBXaHkgdGhvc2Ugc2VydmljZXMgY2Fubm90IGJlIGNvbmZp Z3VyZWQgdXNpbmcgREhDUHY2PyBCZWZvcmUgZGVzaWduaW5nIGEgc29sdXRpb24sIHdlIG5lZWQg dW5kZXJzdGFuZCB0aGUgcmVxdWlyZW1lbnRzIGFuZCB0aGUgbmVlZHMgZmlyc3QuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPk9mIGNvdXJzZSwgaW4gSVB2NiBvbmx5IEludGVybmV0IHdoZXJlIHRoZXJlIGlzIG5vIGRl bWFuZCBmb3IgSVB2NCBzZXJ2aWNlcywgd2Ugc2hvdWxkIHVzZSBESENQdjYuIEJ1dCBESENQdjQt b3Zlci1ESENQdjYgY2FuIGFsc28gd29yayBpbiB0aGlzIGNhc2UuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5b TWVkXSDigKYgZXhjZXB0IHRoYXQgZGhjcHY0LW92ZXItZGhjcHY2IGludHJvZHVjZXMgbW9yZSBj b21wbGV4aXR5IGZvciBub3Qgb2J2aW91cyByZWFzb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5CZXN0IFJlZ2Fy ZHMsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UWk8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20nPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkNoZWVycyw8YnI+TWVk PGJyPjxicj4mZ3Q7LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDtEZSZuYnNwOzogUWkgU3VuIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnN1bnFpLnRodUBnbWFpbC5jb20iPnN1bnFpLnRodUBnbWFpbC5jb208L2E+XTxi cj4mZ3Q7RW52b3nDqSZuYnNwOzogbHVuZGkgMTUgYXZyaWwgMjAxMyAwNzo1Njxicj4mZ3Q7w4Am bmJzcDs6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xOPGJyPiZndDtDYyZuYnNwOzogVG9tZWsg TXJ1Z2Fsc2tpOyA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3Jn PC9hPjsgU29mdHdpcmVzICg8YSBocmVmPSJtYWlsdG86c29mdHdpcmVzQGlldGYub3JnIj5zb2Z0 d2lyZXNAaWV0Zi5vcmc8L2E+KTxicj4mZ3Q7T2JqZXQmbmJzcDs6IFJlOiBbZGhjd2ddIEFkb3B0 aW9uIGNhbGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NjxvOnA+PC9vOnA+ PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0Ozxicj4mZ3Q7PGJyPiZndDtEZWFy IE1lZCw8YnI+Jmd0Ozxicj4mZ3Q7VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBIZXJlIGlzIG15 IHVuZGVyc3RhbmRpbmcuPGJyPiZndDs8YnI+Jmd0O0lNSE8sIGRlZmluaW5nIG9wdGlvbnMgaW4g REhDUHY2IHNlZW1zIHRvIGludHJvZHVjZSBsZXNzIGNvbXBsZXhpdHkgaW48YnI+Jmd0O3Byb3Rv Y29sLiBIb3dldmVyLCB3ZSBkbyBub3Qga25vdyBmb3Igbm93IHdoaWNoIG9wdGlvbnMgYXJlIG5l ZWRlZCBpbiB0aGU8YnI+Jmd0O2Z1dHVyZS4gSWYgd2UgaGF2ZSB0byBwb3J0IERIQ1B2NCBvcHRp b25zIGludG8gREhDUHY2LCBob3cgbWFueSB0aW1lczxicj4mZ3Q7c2hvdWxkIHdlIGRvIHRoZSB3 b3JrPyBMaWtlIG9uZSBuZXcgb3B0aW9uIHBlciAyIHllYXJzLCBvciByZWRlZmluaW5nIGFsbDxi cj4mZ3Q7REhDUHY0IG9wdGlvbnMgaW50byBESENQdjYgYXQgb25lIHRpbWU/IFRoZSBwcm9wb3Nl ZCBzb2x1dGlvbiB0cmllcyB0bzxicj4mZ3Q7YXZvaWQgcG9sbHV0aW5nIHRoZSBESENQdjYgb3B0 aW9uIHNwYWNlLCB3aGljaCBpcyBuZWNlc3NhcnkgZm9yIHRyYW5zaXRpb248YnI+Jmd0O2luIERI Q1AuPGJyPiZndDs8YnI+Jmd0O0Fub3RoZXIgcG9pbnQgaXMgdGhhdCwgZGVmaW5pbmcgb3B0aW9u KHMpIC8gY29udGFpbmVyIHdvdWxkIHJlcXVpcmUgdGhlPGJyPiZndDtESENQdjYgZW5naW5lIHRv IGhhbmRsZSBESENQdjQgb3B0aW9ucywgd2hpY2ggd291bGQgaW50cm9kdWNlIG1vcmU8YnI+Jmd0 O2NvbXBsZXhpdHkgdG8gdGhlIGxvZ2ljIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBlbmQgcG9pbnRz LiBUaGUgcHJvcG9zZWQ8YnI+Jmd0O3NvbHV0aW9uIGxldmVyYWdlcyB0aGUgREhDUHY0IGVuZ2lu ZSBmb3IgREhDUHY0IG1lc3NhZ2VzIC8gb3B0aW9ucyBhbmQ8YnI+Jmd0O0RIQ1B2NiBlbmdpbmUg Zm9yIERIQ1B2NiBtZXNzYWdlcyAvIG9wdGlvbnMuIFRoZSBlbmQgcG9pbnRzIHdvdWxkPGJyPiZn dDtjb21wYXRpYmxlIHRvIGJvdGggREhDUHY0IHByb2Nlc3MgYW5kIERIQ1B2NiBwcm9jZXNzLiBU aGlzIGlzIG1vcmUgc3VpdGFibGU8YnI+Jmd0O2ZvciB0aGUgdHJhbnNpdGlvbi48YnI+Jmd0Ozxi cj4mZ3Q7QSB0aGlyZCBjb25zaWRlcmF0aW9uIGlzLCBpbiB0aGUgY2FzZSBvZiBJUHY2IHRyYW5z aXRpb24sIHRoZSBESENQIGNsaWVudDxicj4mZ3Q7KG9uIHRoZSB0dW5uZWwgZW5kcG9pbnQpIGlz IGJvdW5kIHRvIGJlIG1vZGlmaWVkLiBXZSB0aGluayBpdCBiZXR0ZXIgdG88YnI+Jmd0O21vZGlm eSB0aGUgY2xpZW50IGNvbXBsZXRlbHkgZm9yIHRoZSB0cmFuc2l0aW9uIHB1cnBvc2UuPGJyPiZn dDs8YnI+Jmd0O0xhc3QgYnV0IG5vdCB0aGUgbGVhc3QsIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBp cyBiYXNlZCBvbiB0aGUgREhDUHY2PGJyPiZndDtpbmZyYXN0cnVjdHVyZSwgd2hpY2ggaGFzIGJl ZW4gZGVwbG95ZWQgaW4gb3BlcmF0b3JzJyBuZXR3b3Jrcy48YnI+Jmd0Ozxicj4mZ3Q7VGhlIERI Q1B2NCBvdmVyIERIQ1B2NiBtZWNoYW5pc20gaXMgYW4gYXJjaGl0ZWN0dXJhbCBkZXZlbG9wbWVu dCBmb3IgREhDUDxicj4mZ3Q7cHJvdG9jb2wgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIGZvciBj b25maWd1cmluZyBJUHY0IHBhcmFtZXRlcnMgYWNyb3NzPGJyPiZndDt0aGUgSVB2NiBuZXR3b3Jr LiBXZSB0aGluayBpdCBpcyBpbXBvcnRhbnQgZm9yIHRoZSBESEMgV0cgdG8gd29yayBvbiBpdC48 YnI+Jmd0Ozxicj4mZ3Q7QmVzdCBSZWdhcmRzLDxicj4mZ3Q7UWkgU3VuPGJyPiZndDsoU29ycnkg Zm9yIHJlc2VuZGluZywgdHJ5IHRvIHN5bmNocm9uaXplIHdpdGggc29mdHdpcmUgTUwuLi4pPGJy PiZndDs8YnI+Jmd0O09uIDIwMTMtNC0xMiwgYXQgPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJN UyBHb3RoaWMiJz7kuIvljYg8L3NwYW4+Nzo0NywgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZn dDs8YnI+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4mZ3Q7PGJy PiZndDsmZ3Q7IERlYXIgYWxsLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAoSSBjYyBzb2Z3dGly ZSBhcyB0aGlzIHdvcmsgaXMgYWxzbyByZWxldmFudCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAuKTxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIGRvIG5vdCBzdXBwb3J0IHRoaXMgd29yayBhcyBpdCBp bmR1Y2VzIG1vcmUgY29tcGxleGl0eSBjb21wYXJlZCB0byBqdXN0PGJyPiZndDtkZWZpbmluZyBh ZGVxdWF0ZSBvcHRpb24gaW4gZGhjcHY2LiBEZWZpbmluZyBvbmUgY29udGFpbmVyIG9yIGZldyBE SENQdjY8YnI+Jmd0O29wdGlvbnMgaXMgbXVjaCBtb3JlIHNpbXBsZXIgdGhhdCB0aGUgcHJvcG9z ZWQgYXBwcm9hY2guPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IENoZWVycyw8YnI+Jmd0OyZndDsg TWVkPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS08YnI+Jmd0OyZndDsmZ3Q7IERlIDogPGEgaHJlZj0ibWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0 Zi5vcmciPmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmciPmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBEZSBs YSBwYXJ0PGJyPiZndDtkZTxicj4mZ3Q7Jmd0OyZndDsgVG9tZWsgTXJ1Z2Fsc2tpPGJyPiZndDsm Z3Q7Jmd0OyBFbnZvecOpIDogbWVyY3JlZGkgMyBhdnJpbCAyMDEzIDE5OjQxPGJyPiZndDsmZ3Q7 Jmd0OyDDgCA6IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8 L2E+PGJyPiZndDsmZ3Q7Jmd0OyBPYmpldCA6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFm dC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsgSGkgYWxsLDxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IFRoaXMgZHJhZnQg aXMgYSByZXN1bHQgb2YgdGhlIGRpc2N1c3Npb24gd2UgaGFkIGR1cmluZyBsYXN0IG1lZXRpbmcg aW48YnI+Jmd0OyZndDsmZ3Q7IE9ybGFuZG8uIFdlIGhhdmUgdmVyeSBwcm9kdWN0aXZlIGRpc2N1 c3Npb24gYWJvdXQgSVB2NCBob3N0czxicj4mZ3Q7Jmd0OyZndDsgY29uZmlndXJhdGlvbiBpbiBJ UHY2LW9ubHkgbmV0d29yay4gQWZ0ZXIgd2UgcmVhY2hlZCB3aGF0IGxvb2tlZCBsaWtlIGE8YnI+ Jmd0OyZndDsmZ3Q7IGNvbnNlbnN1cyBpbiB0aGUgbWVldGluZyByb29tLCBjb3VwbGUgZm9sa3Mg dm9sdW50ZWVyZWQgdG8gd3JpdGUgZG93bjxicj4mZ3Q7Jmd0OyZndDsgdGhlIGRyYWZ0IHRoYXQg c3VtbWFyaXplcyB0aGF0IHBlcmNlaXZlZCBjb25zZW5zdXMuIFRoaXMgZHJhZnQgaXMgYTxicj4m Z3Q7Jmd0OyZndDsgcHJvZHVjdCBvZiB0aGlzIGVmZm9ydC48YnI+Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyBBcyByZXF1ZXN0ZWQgYnkgYXV0aG9ycywgd2UgYXJlIGFubm91bmNpbmcgYWRv dGlvbiBjYWxsIG9uPGJyPiZndDsmZ3Q7Jmd0OyBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXIt ZGhjcHY2LTAxLiBUaGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvPGJyPiZndDsmZ3Q7Jmd0 OyBjb25maXJtIHdoZXRoZXIgdGhlcmUgaXMgV0cgY29uc2Vuc3VzIHRvIGFkb3B0IHRoaXMgd29y ayBhcyBESEMgV0c8YnI+Jmd0OyZndDsmZ3Q7IGRyYWZ0LiBQbGVhc2Ugc3RhdGUgd2hldGhlciBv ciBub3QgeW91J3JlIGluIGZhdm9yIG9mIHRoZSBhZG9wdGlvbiBieTxicj4mZ3Q7Jmd0OyZndDsg cmVwbHlpbmcgdG8gdGhpcyBtYWlsLiBJZiB5b3UgYXJlIG5vdCBpbiBmYXZvciwgcGxlYXNlIGFs c28gc3RhdGUgeW91cjxicj4mZ3Q7Jmd0OyZndDsgb2JqZWN0aW9ucyBpbiB5b3VyIHJlc3BvbnNl LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb21wbGV0ZSBvbiAyMDEzLTxicj4mZ3Q7MDQtPGJy PiZndDsmZ3Q7Jmd0OyAxNy48YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBSZWdhcmRz LDxicj4mZ3Q7Jmd0OyZndDsgQmVybmllICZhbXA7IFRvbWVrPGJyPiZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsgT24gMDMuMDQuMjAxMyAxOToyMCwgTWFyY2luIFNpb2RlbHNraSB3cm90ZTo8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBJbiB0aGUgbmFtZSBvZiBhdXRob3JzIG9mIGRyYWZ0LXNjc2tm LWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYgSSBhbTxicj4mZ3Q7YXNraW5nPGJyPiZndDsmZ3Q7Jmd0 OyZndDsgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYnkgREhDIFdHLjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgVGhlIGxhdGVzdCB2ZXJzaW9uICgtMDEpIGlz IGF2YWlsYWJsZSBoZXJlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nza2Yt ZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTwv YT48YnI+Jmd0OyZndDsmZ3Q7IDAxLnR4dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNw djYtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z Y3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxPC9hPjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gd2hl cmVieSBJUHY0IGNsaWVudCBvYnRhaW5zIGl0czxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmZpZ3Vy YXRpb24gZnJvbSB0aGUgREhDUHY0IHNlcnZlciBzZXBhcmF0ZWQgZnJvbSB0aGUgY2xpZW50IGJ5 IElQdjYtPGJyPiZndDsmZ3Q7Jmd0OyZndDsgb25seSBuZXR3b3JrIGhhdmluZyBESENQdjYgc2Vy dmljZS4gVGhpcyBtZWNoYW5pc20gaXMgZnJlcXVlbnRseTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IHJl ZmVycmVkIGFzICZxdW90O0RIQ1B2NC1vdmVyLURIQ1B2NiZxdW90Oy48YnI+Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBESENQdjQgY2xpZW50J3MgcmVxdWVzdCBpcyBj YXJyaWVkIGluIHRoZSBuZXdseSBkZWZpbmVkIERIQ1B2Njxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IG1l c3NhZ2VzL29wdGlvbiB0by9mcm9tIHRoZSBzZXJ2ZXIgYW5kIGNhbiBiZSBzZW50IGVpdGhlciB0 aHJvdWdoIGE8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyByZWxheSBvciBkaXJlY3RseS48YnI+Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyBNYXJjaW48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGRoY3dnIG1haWxpbmcg bGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PGJyPiZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsgZGhjd2cgbWFpbGlu ZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRo Y3dnQGlldGYub3JnPC9hPjxicj4mZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PGJyPiZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7IGRoY3dn IG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmci PmRoY3dnQGlldGYub3JnPC9hPjxicj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZzwvYT48YnI+PGJyPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmRoY3dnIG1haWxpbmcgbGlzdDxi cj48YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zzwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvYm9keT48L2h0bWw+ --_000_94C682931C08B048B7A8645303FDC9F36EC2D7C478PUEXCB1Bnante_-- From jiangsheng@huawei.com Mon Apr 15 02:45:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C983E21F939C for ; Mon, 15 Apr 2013 02:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYvMC0uiZ+3Q for ; Mon, 15 Apr 2013 02:45:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD121F9399 for ; Mon, 15 Apr 2013 02:45:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQJ76030; Mon, 15 Apr 2013 09:45:39 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Apr 2013 10:45:31 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Apr 2013 10:45:36 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.76]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Mon, 15 Apr 2013 17:45:30 +0800 From: Sheng Jiang To: Tomek Mrugalski , dhcwg Thread-Topic: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 Thread-Index: AQHONHmGQ0BnpZkv4UCeA7Q/OzRVkpjXEiGw Date: Mon, 15 Apr 2013 09:45:29 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA19456@nkgeml512-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> <5162F5DB.7010404@gmail.com> In-Reply-To: <5162F5DB.7010404@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:45:42 -0000 SSBkbyBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LiBVc2VmdWwgd29yay4gSG93 ZXZlciwgSSBkbyB0aGluayB0aGlzIGRyYWZ0IHNob3VsZCBnbyBmdXJ0aGVyIHRvIGluY2x1ZGUg Ym90aCB1bmtub3duIG1lc3NhZ2UgYW5kIHVua25vd24gT1BUSU9OUy4NCg0KQmVzdCByZWdhcmRz LA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBkaGN3Zy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm DQo+T2YgVG9tZWsgTXJ1Z2Fsc2tpDQo+U2VudDogVHVlc2RheSwgQXByaWwgMDksIDIwMTMgMTI6 NTMgQU0NCj5UbzogZGhjd2cNCj5TdWJqZWN0OiBSZTogW2RoY3dnXSBBZG9wdGlvbiBjYWxsIG9u DQo+ZHJhZnQtY3NsLWRoYy1kaGNwdjYtdW5rbm93bi1tc2ctMzMxNXVwZGF0ZS0wMA0KPg0KPk9u IDAzLjA0LjIwMTMgMjA6MDQsIEJlcm5pZSBWb2x6ICh2b2x6KSB3cm90ZToNCj4+IFdoaWxlIEkg dGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBXRyB0byBhZG9wdCB0aGlzIGRvY3VtZW50 LCBJIGRvIGhhdmUNCj5jb21tZW50cyBvbiB0aGUgZHJhZnQgaXRzZWxmLg0KPlRoaXMgaXMgYSBz bWFsbCwgYnV0IGltcG9ydGFudCBkcmFmdC4gQnkgY2xhcmlmeWluZyB0aGF0IHJlbGF5cyBtdXN0 DQo+Zm9yd2FyZCB1bmtub3duIG1lc3NhZ2VzIGl0IHByb3ZpZGVzIGZvcndhcmQgY29tcGF0aWJp bGl0eSB3aXRoIGFueQ0KPmZ1dHVyZSBleHRlbnNpb25zIHRoYXQgZGVmaW5lIG5ldyBtZXNzYWdl IHR5cGVzLiBXZSBrbm93IHRoYXQgdGhlcmUncw0KPm9uZSBhcm91bmQgdGhlIGNvcm5lciBhbHJl YWR5LCBidXQgdGhlcmUgbWF5IGJlIG1vcmUgYWhlYWQuDQo+DQo+SXQgaXMgdmVyeSB1c2VmdWwu IEkgZG8gc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LiBUaGlzIGlzDQo+ZGVmaW5pdGVs eSBzb21ldGhpbmcgREhDIFdHIHNob3VsZCB3b3JrIG9uLiBGb3J0dW5hdGVseSwgdGhlcmUncyBu b3QNCj5tdWNoIHdvcmsgbGVmdCB0byBiZSBkb25lLg0KPg0KPk1pbm9yIGNvbW1lbnQ6IEkgd291 bGQgYWRkIGluIHNlY3Rpb24gMy4yICJyZWdhcmRsZXNzIG9mIHRoZSBtZXNzYWdlDQo+dHlwZSBp biBSZWxheSBNZXNzYWdlIG9wdGlvbiIuDQo+DQo+VG9tZWsNCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRo Y3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3 Zw0K From jiangsheng@huawei.com Mon Apr 15 02:51:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B4E21F935B for ; Mon, 15 Apr 2013 02:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAPCERjHogR8 for ; Mon, 15 Apr 2013 02:50:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0921F9357 for ; Mon, 15 Apr 2013 02:50:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQJ76526; Mon, 15 Apr 2013 09:50:58 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Apr 2013 10:50:43 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Apr 2013 10:50:47 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.76]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 15 Apr 2013 17:50:42 +0800 From: Sheng Jiang To: Simon Perreault , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJqyF9XmnUyaUu1R3vq433XEJjFWw6AgBHBD0A= Date: Mon, 15 Apr 2013 09:50:41 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA19466@nkgeml512-mbx.china.huawei.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <515D592B.4040609@viagenie.ca> In-Reply-To: <515D592B.4040609@viagenie.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:51:00 -0000 Pj4gQXMgcmVxdWVzdGVkIGJ5IGF1dGhvcnMsIHdlIGFyZSBhbm5vdW5jaW5nIGFkb3Rpb24gY2Fs bCBvbg0KPj4gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMS4gVGhpcyBjYWxs IGlzIGJlaW5nIGluaXRpYXRlZCB0bw0KPj4gY29uZmlybSB3aGV0aGVyIHRoZXJlIGlzIFdHIGNv bnNlbnN1cyB0byBhZG9wdCB0aGlzIHdvcmsgYXMgREhDIFdHDQo+PiBkcmFmdC4gUGxlYXNlIHN0 YXRlIHdoZXRoZXIgb3Igbm90IHlvdSdyZSBpbiBmYXZvciBvZiB0aGUgYWRvcHRpb24gYnkNCj4+ IHJlcGx5aW5nIHRvIHRoaXMgbWFpbC4gSWYgeW91IGFyZSBub3QgaW4gZmF2b3IsIHBsZWFzZSBh bHNvIHN0YXRlIHlvdXINCj4+IG9iamVjdGlvbnMgaW4geW91ciByZXNwb25zZS4gVGhpcyBhZG9w dGlvbiBjYWxsIHdpbGwgY29tcGxldGUgb24gMjAxMy0wNC0xNy4NCj4NCj5UaGlzIGxvb2tzIHZl cnkgZ29vZC4gSSB3b3VsZCBmYXZvdXIgYWRvcHRpb24sIA0KDQorMS4NCg0KU2hlbmcNCg0KPmJ1 dCBJIHdvdWxkIHJlYWxseSBsaWtlDQo+dG8gc2VlIHNvbWUgZGlzY3Vzc2lvbiBiZWZvcmUuDQo+ DQo+U29tZSBmZWVkYmFjazoNCj4NCj4tIEluIHNlY3Rpb24gIjYuIENsaWVudCBCZWhhdmlvciIs IGl0J3Mgbm90IGNsZWFyIG9uIHdoaWNoIElQdjYNCj5pbnRlcmZhY2UgdGhlIHJlcXVlc3QgZm9y IElQdjQgcGFyYW1ldGVycyBpcyB0byBiZSBzZW50LiBUaGF0IGtub3dsZWRnZQ0KPndvdWxkIGRl cGVuZCBvbiB0aGUgcHJvdG9jb2wgdGhhdCB1c2VzIERIQ1B2NC1vdmVyLUlQdjYuIEZvciBleGFt cGxlLCBpZg0KPnlvdSBhcmUgcHJvdmlzaW9uaW5nIGFuIElQdjQtb3Zlci1JUHY2IHR1bm5lbCBp bnRlcmZhY2UsIHlvdSB3b3VsZCBzZW5kDQo+dGhlIEJPT1RSRVFVRVNUNiBtZXNzYWdlIG9uIHRo ZSB0dW5uZWwncyB1bmRlcmx5aW5nIElQdjYgaW50ZXJmYWNlLg0KPlN1Z2dlc3Rpb246IFRoaXMg ZG9jdW1lbnQgc2hvdWxkIHNheSB0aGF0IGZ1dHVyZSBkb2N1bWVudHMgdGhhdCBkZWZpbmUNCj51 c2VzIG9mIERIQ1B2NC1vdmVyLUlQdjYgTVVTVCBzcGVjaWZ5IHdoaWNoIElQdjYgaW50ZXJmYWNl IGlzIHRvIGJlIHVzZWQNCj5ieSB0aGUgY2xpZW50Lg0KPg0KPi0gSW4gc2VjdGlvbiAiOC4gU2Vy dmVyIEJlaGF2aW9yIiwgaXQgaXMgc2FpZCB0aGF0IHRoZSByZXF1ZXN0IGlzDQo+InBhc3NlZCB0 byB0aGUgREhDUHY0IHNlcnZlciBlbmdpbmUiLiBJcyB0aGlzIGFuIGltcGxlbWVudGF0aW9uIGRl dGFpbA0KPihpbiB3aGljaCBjYXNlIGl0IGNvdWxkIGJlIHJlbW92ZWQpLCBvciBkb2VzIGl0IGFj dHVhbGx5IG1lYW4gdGhhdCB0aGUNCj5JUHY0IG1lc3NhZ2UgY291bGQgYmUgcGFzc2VkIG92ZXIg dGhlIG5ldHdvcmsgdG8gYW4gdW5tb2RpZmllZCBESENQdjQNCj5zZXJ2ZXIgKGluIHdoaWNoIGNh c2UgaXQgY291bGQgYmUgbW9yZSBleHBsaWNpdCk/DQo+DQo+LSBTZWN0aW9uICI5LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyIgc2F5czogIkRIQ1B2NiBpcyBtYWRlIGENCj4ndHJhbnNwb3J0IHBy b3RvY29sJyBmb3IgREhDUHY0IG1lc3NhZ2VzIG92ZXIgYW4gSVB2NiBuZXR3b3JrIi4gVGhpcyBp cw0KPm5vdCB0cnVlIHVubGVzcyB5b3UgY2FuIHVzZSB0aGlzIHdpdGggYSBwdXJlIERIQ1B2NCBj bGllbnQgb24gb25lIHNpZGUNCj5hbmQgYSBwdXJlIERIQ1B2NCBzZXJ2ZXIgb24gdGhlIG90aGVy LiBJdCBkb2Vzbid0IHNlZW0gdG8gYmUgdGhlIGNhc2UNCj5hY2NvcmRpbmcgdG8gdGhlIHJlc3Qg b2YgdGhlIGRyYWZ0IGFuZCBmaWd1cmUgMSBpbiBwYXJ0aWN1bGFyLiBTbywgaXMgaXQNCj5vciBp cyBpdCBub3QgYSB0cmFuc3BvcnQgcHJvdG9jb2wgZm9yIERIQ1B2ND8NCj4NCj4NCj5OaXQ6DQo+ DQo+LSBTZWN0aW9uIDg6ICJUaGlzIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRoZSBESENQdjQgc2Vy dmVyIGVuZ2luZSwgd2hpY2gNCj5nZW5lcmF0ZXMgYSByZXNwb25zZSAqdG8gdGhlKiBhcyBzcGVj aWZpZWQgaW4gW1JGQzIxMzFdLiINCj4ocmVtb3ZlICJ0byB0aGUiKQ0KPg0KPg0KPlNpbW9uDQo+ LS0NCj5EVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxsYXRp b24udmlhZ2VuaWUuY2ENCj5OQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAgICAgICAgLS0+IGh0dHA6 Ly9lY2R5c2lzLnZpYWdlbmllLmNhDQo+U1RVTi9UVVJOIHNlcnZlciAgICAgICAgICAgICAgIC0t PiBodHRwOi8vbnVtYi52aWFnZW5pZS5jYQ0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From rajiva@cisco.com Mon Apr 15 03:03:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD621F84E0; Mon, 15 Apr 2013 03:03:00 -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 Pk8mANcj5Mlq; Mon, 15 Apr 2013 03:02:59 -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 A252A21F84B2; Mon, 15 Apr 2013 03:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36783; q=dns/txt; s=iport; t=1366020178; x=1367229778; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZS3a4rRAI+xVuLbIeWpn4abRWkAvVMkw3JSAPLH+0mQ=; b=L6T1DA/MhANkn4tYYDhj6GxZ25+687So69oLAHlyKBUKudMAqg1yXXKM PFVHWjQ1BtQ5XuNhfMNyZumEV3YmCDWAW2GW3zjmB8R0LVWMZ5mZHo9Bt MH0tQxXtYbJe5kbgF9oyUUS/f1Lp7hMIkwxjYhf5br9p5/pZeQjMrNn48 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAEvPa1GtJV2a/2dsb2JhbABQgkJENoMwtRoBiDUNfBZ0gh8BAQEEAQEBIAo6BwsQAgEGAhggBwMCAgIfBgsUEQEBBA4FCRKHZwMPDI4KmwSICQ2JXYxEgSGBFxcEBgGCLjJhA5J+giSBY4EhilSFHIMLgXM X-IronPort-AV: E=Sophos;i="4.87,474,1363132800"; d="scan'208,217";a="198586469" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 15 Apr 2013 10:02:57 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3FA2vNI006862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 10:02:57 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.247]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 05:02:57 -0500 From: "Rajiv Asati (rajiva)" To: "mohamed.boucadair@orange.com" Thread-Topic: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac45nfkOG3CvbrVoTqWsHqLYpp3TBwADQwkgAA2d+4AAAT7jgP//s90m Date: Mon, 15 Apr 2013 10:02:57 +0000 Message-ID: References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CEB7ADD2C5444CFFBFFA6404F726C7C2ciscocom_" MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:03:00 -0000 --_000_CEB7ADD2C5444CFFBFFA6404F726C7C2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIE1lZC4gSW4gcmVhbGl0eSwgaXQgaXMgaGlnaGx5IHVubGlrZWx5IHRoYXQg ZWFjaCBhbmQgZXZlcnkgRGhjcHY0IG9wdGlvbiB3b3VsZCBiZSBuZWVkZWQgZm9yIGFuIGlwdjYg b25seSBob3N0Lg0KDQpBbmQgdGhlIG9uZXMgdGhhdCBhcmUgcmVhbGx5IG5lZWRlZCwgIHdvdWxk IGJldHRlciBtb3ZlIHRvIGRoY3ZwdjYgc29vbmVyIHRoYW4gbGF0ZXIuIEl0IHdvdWxkIGJlIHBy dWRlbnQgZm9yIHVzIHRvIGRvIGZpbmQgdGhlIGRlbHRhIGluc3RlYWQgb2YgY2Fycnlpbmcgb3Zl ciB0aGUgbGVnYWN5IGFuZCBnZXR0aW5nIHRoZSByZWxldmFudCBvbmVzIGZpeGVkLiBPciBoYXMg dGhhdCB3b3JrIGJlZW4gZG9uZSBhbHJlYWR5Pw0KDQpDaGVlcnMsDQpSYWppdg0KDQpTZW50IGZy b20gbXkgUGhvbmUNCg0KT24gQXByIDE1LCAyMDEzLCBhdCA1OjM2IEFNLCAibW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPj4gd3JvdGU6DQoNClJlLSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywN Ck1lZA0KDQpEZSA6IFFpIFN1biBbbWFpbHRvOnN1bnFpLmNzbmV0LnRodUBnbWFpbC5jb21dDQpF bnZvecOpIDogbHVuZGkgMTUgYXZyaWwgMjAxMyAxMTowMA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1l ZCBPTE5DL09MTg0KQ2MgOiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+OyBT b2Z0d2lyZXMgKHNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPikN Ck9iamV0IDogUmU6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhj cHY0LW92ZXItZGhjcHY2DQoNCkRlYXIgTWVkLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KRXhj ZXB0ICJJUHY0IGFkZHJlc3NpbmciLXJlbGF0ZWQgY29uZmlndXJhdGlvbiwgd2hhdCBhZGRpdGlv bmFsIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBjYW4gYmUgcHJvdmlzaW9uZWQgd2l0aCBESENQ djQgYW5kIG5vdCB3aXRoIERIQ1B2Nj8NCg0KW1FpXSBUaGVyZSBhcmUgb3ZlciAyMDAgREhDUHY0 IG9wdGlvbnMgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gcHJvdmlkZSBJUHY0IHNlcnZpY2VzLiBJ biB0aGUgcGVyaW9kIG9mIHRyYW5zaXRpb24sDQpbTWVkXSBUaGUgcXVlc3Rpb24gaXMgbm90IGhv dyBtYW55IGRoY3B2NCBleGlzdCwgYnV0IHdoaWNoIG9uZXMgYXJlIHJlYWxseSBuZWVkZWQgd2hl biB0aGUgaG9zdCBpcyBJUHY2LWVuYWJsZWQuDQoNCg0Kc29tZSBzZXJ2aWNlIHByb3ZpZGVycyBh bmQgc2VydmljZXMgbWF5IHJlbWFpbiBpbiBJUHY0IGZvciBzb21lIHRpbWUsIHdoaWxlIGVuZCB1 c2VycyBtYXkgZGVtYW5kIHRoZXNlIElQdjQgc2VydmljZXMgdG8gYmUgZGVsaXZlcmVkIG92ZXIg SVB2Ni4gVGhlIHJlcXVpcmVkIGluZm8gbWF5IGJlIG1vcmUgdGhhbiBJUHY0IGFkZHJlc3NlcyAo cG9ydCBzZXQpLiBBcyBmb3IgZXhhbXBsZXMsIElNSE8sIFNJUCBzZXJ2ZXIgb3B0aW9uIGFuZA0K W01lZF0gVGhpcyBpcyBkb2FibGUgdXNpbmcgb3B0aW9uIDIxLiBUaGUgbmFtZSBjYW4gYmUgcmVz b2x2ZWQgdG8gYW4gSVB2NiBvciBhbiBJUHY0IGFkZHJlc3MuIE5vdGhpbmcgcHJldmVudCBmcm9t IGRvaW5nIHNvLg0KDQpOVFAgc2VydmVyIG9wdGlvbiBhcmUgcG90ZW50aWFsIGN1c3RvbWVycyBm b3IgdGhpcyB1c2FnZS4NCltNZWRdIFRoaXMgaXMgZG9hYmxlIHVzaW5nIGRoY3B2Ni4gV2h5IHRo ZSB1c2UgZGhwdjQtb3Zlci1kaGNwdjYgaXMgYSBtdXN0Pw0KDQpUaGVyZSBtYXkgYmUgbW9yZSwg YmVjYXVzZSBkZW1hbmRzIGFyZSBhcmlzaW5nIHdpdGggdGltZSBnb2luZyBvbi4NCltNZWRdIEni gJltIHN0aWxsIG5vdCBzZWVpbmcgYW55IHBhcnRpY3VsYXIgZGVtYW5kIHdoaWNoIGNhbm5vdCBi ZSBob25vcmVkIHVzaW5nIGRoY3B2Ni4NCg0KDQpXaHkgaW4gdGhlIGZ1dHVyZSwgYW4gSVB2Ni1l bmFibGVkIG5vZGUgd2lsbCByZXF1aXJlIHRvIHJldHJpZXZlIGNvbmZpZ3VyYXRpb24gdXNpbmcg REhDUHY0LW92ZXItREhDUHY2IGFuZCBub3QgZGlyZWN0bHkgdXNpbmcgREhDUHY2Pw0KDQpbUWld IFdlIGFyZSB0YWxraW5nIGFib3V0IElQdjYtZW5hYmxlZCBub2RlIGluIElQdjQvSVB2NiB0cmFu c2l0aW9uIHBlcmlvZCwgd2hlbiBJUHY0IGFuZCBJUHY2IHNlcnZpY2VzIGFyZSBjb2V4aXN0ZWQu IFVzaW5nIERIQ1B2NC1vdmVyLURIQ1B2NiBjYW4gZ3VhcmFudGVlIGFsbCBESENQLWJhc2VkIHNl cnZpY2VzIHRvIGJlIGNvbmZpZ3VyZWQgY29ycmVjdGx5Lg0KDQpbTWVkXSBXaGF0IGFyZSB0aG9z ZSBzZXJ2aWNlcz8gV2h5IHRob3NlIHNlcnZpY2VzIGNhbm5vdCBiZSBjb25maWd1cmVkIHVzaW5n IERIQ1B2Nj8gQmVmb3JlIGRlc2lnbmluZyBhIHNvbHV0aW9uLCB3ZSBuZWVkIHVuZGVyc3RhbmQg dGhlIHJlcXVpcmVtZW50cyBhbmQgdGhlIG5lZWRzIGZpcnN0Lg0KDQpPZiBjb3Vyc2UsIGluIElQ djYgb25seSBJbnRlcm5ldCB3aGVyZSB0aGVyZSBpcyBubyBkZW1hbmQgZm9yIElQdjQgc2Vydmlj ZXMsIHdlIHNob3VsZCB1c2UgREhDUHY2LiBCdXQgREhDUHY0LW92ZXItREhDUHY2IGNhbiBhbHNv IHdvcmsgaW4gdGhpcyBjYXNlLg0KDQpbTWVkXSDigKYgZXhjZXB0IHRoYXQgZGhjcHY0LW92ZXIt ZGhjcHY2IGludHJvZHVjZXMgbW9yZSBjb21wbGV4aXR5IGZvciBub3Qgb2J2aW91cyByZWFzb25z Lg0KDQpCZXN0IFJlZ2FyZHMsDQpRaQ0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPkRlIDogUWkgU3VuIFttYWlsdG86c3VucWkudGh1QGdtYWlsLmNvbTxt YWlsdG86c3VucWkudGh1QGdtYWlsLmNvbT5dDQo+RW52b3nDqSA6IGx1bmRpIDE1IGF2cmlsIDIw MTMgMDc6NTYNCj7DgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Q2MgOiBUb21layBN cnVnYWxza2k7IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz47IFNvZnR3aXJl cyAoc29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+KQ0KPk9iamV0 IDogUmU6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92 ZXItZGhjcHY2DQo+DQo+DQo+RGVhciBNZWQsDQo+DQo+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl LiBIZXJlIGlzIG15IHVuZGVyc3RhbmRpbmcuDQo+DQo+SU1ITywgZGVmaW5pbmcgb3B0aW9ucyBp biBESENQdjYgc2VlbXMgdG8gaW50cm9kdWNlIGxlc3MgY29tcGxleGl0eSBpbg0KPnByb3RvY29s LiBIb3dldmVyLCB3ZSBkbyBub3Qga25vdyBmb3Igbm93IHdoaWNoIG9wdGlvbnMgYXJlIG5lZWRl ZCBpbiB0aGUNCj5mdXR1cmUuIElmIHdlIGhhdmUgdG8gcG9ydCBESENQdjQgb3B0aW9ucyBpbnRv IERIQ1B2NiwgaG93IG1hbnkgdGltZXMNCj5zaG91bGQgd2UgZG8gdGhlIHdvcms/IExpa2Ugb25l IG5ldyBvcHRpb24gcGVyIDIgeWVhcnMsIG9yIHJlZGVmaW5pbmcgYWxsDQo+REhDUHY0IG9wdGlv bnMgaW50byBESENQdjYgYXQgb25lIHRpbWU/IFRoZSBwcm9wb3NlZCBzb2x1dGlvbiB0cmllcyB0 bw0KPmF2b2lkIHBvbGx1dGluZyB0aGUgREhDUHY2IG9wdGlvbiBzcGFjZSwgd2hpY2ggaXMgbmVj ZXNzYXJ5IGZvciB0cmFuc2l0aW9uDQo+aW4gREhDUC4NCj4NCj5Bbm90aGVyIHBvaW50IGlzIHRo YXQsIGRlZmluaW5nIG9wdGlvbihzKSAvIGNvbnRhaW5lciB3b3VsZCByZXF1aXJlIHRoZQ0KPkRI Q1B2NiBlbmdpbmUgdG8gaGFuZGxlIERIQ1B2NCBvcHRpb25zLCB3aGljaCB3b3VsZCBpbnRyb2R1 Y2UgbW9yZQ0KPmNvbXBsZXhpdHkgdG8gdGhlIGxvZ2ljIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBl bmQgcG9pbnRzLiBUaGUgcHJvcG9zZWQNCj5zb2x1dGlvbiBsZXZlcmFnZXMgdGhlIERIQ1B2NCBl bmdpbmUgZm9yIERIQ1B2NCBtZXNzYWdlcyAvIG9wdGlvbnMgYW5kDQo+REhDUHY2IGVuZ2luZSBm b3IgREhDUHY2IG1lc3NhZ2VzIC8gb3B0aW9ucy4gVGhlIGVuZCBwb2ludHMgd291bGQNCj5jb21w YXRpYmxlIHRvIGJvdGggREhDUHY0IHByb2Nlc3MgYW5kIERIQ1B2NiBwcm9jZXNzLiBUaGlzIGlz IG1vcmUgc3VpdGFibGUNCj5mb3IgdGhlIHRyYW5zaXRpb24uDQo+DQo+QSB0aGlyZCBjb25zaWRl cmF0aW9uIGlzLCBpbiB0aGUgY2FzZSBvZiBJUHY2IHRyYW5zaXRpb24sIHRoZSBESENQIGNsaWVu dA0KPihvbiB0aGUgdHVubmVsIGVuZHBvaW50KSBpcyBib3VuZCB0byBiZSBtb2RpZmllZC4gV2Ug dGhpbmsgaXQgYmV0dGVyIHRvDQo+bW9kaWZ5IHRoZSBjbGllbnQgY29tcGxldGVseSBmb3IgdGhl IHRyYW5zaXRpb24gcHVycG9zZS4NCj4NCj5MYXN0IGJ1dCBub3QgdGhlIGxlYXN0LCB0aGUgcHJv cG9zZWQgc29sdXRpb24gaXMgYmFzZWQgb24gdGhlIERIQ1B2Ng0KPmluZnJhc3RydWN0dXJlLCB3 aGljaCBoYXMgYmVlbiBkZXBsb3llZCBpbiBvcGVyYXRvcnMnIG5ldHdvcmtzLg0KPg0KPlRoZSBE SENQdjQgb3ZlciBESENQdjYgbWVjaGFuaXNtIGlzIGFuIGFyY2hpdGVjdHVyYWwgZGV2ZWxvcG1l bnQgZm9yIERIQ1ANCj5wcm90b2NvbCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgZm9yIGNvbmZp Z3VyaW5nIElQdjQgcGFyYW1ldGVycyBhY3Jvc3MNCj50aGUgSVB2NiBuZXR3b3JrLiBXZSB0aGlu ayBpdCBpcyBpbXBvcnRhbnQgZm9yIHRoZSBESEMgV0cgdG8gd29yayBvbiBpdC4NCj4NCj5CZXN0 IFJlZ2FyZHMsDQo+UWkgU3VuDQo+KFNvcnJ5IGZvciByZXNlbmRpbmcsIHRyeSB0byBzeW5jaHJv bml6ZSB3aXRoIHNvZnR3aXJlIE1MLi4uKQ0KPg0KPk9uIDIwMTMtNC0xMiwgYXQg5LiL5Y2INzo0 NywgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+Pg0KPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+DQo+PiBEZWFyIGFsbCwNCj4+DQo+ PiAoSSBjYyBzb2Z3dGlyZSBhcyB0aGlzIHdvcmsgaXMgYWxzbyByZWxldmFudCBmb3IgdGhlIHdv cmtpbmcgZ3JvdXAuKQ0KPj4NCj4+IEkgZG8gbm90IHN1cHBvcnQgdGhpcyB3b3JrIGFzIGl0IGlu ZHVjZXMgbW9yZSBjb21wbGV4aXR5IGNvbXBhcmVkIHRvIGp1c3QNCj5kZWZpbmluZyBhZGVxdWF0 ZSBvcHRpb24gaW4gZGhjcHY2LiBEZWZpbmluZyBvbmUgY29udGFpbmVyIG9yIGZldyBESENQdjYN Cj5vcHRpb25zIGlzIG11Y2ggbW9yZSBzaW1wbGVyIHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNo Lg0KPj4NCj4+IENoZWVycywNCj4+IE1lZA0KPj4NCj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4+PiBEZSA6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQNCj5kZQ0KPj4+IFRvbWVrIE1ydWdhbHNraQ0K Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAzIGF2cmlsIDIwMTMgMTk6NDENCj4+PiDDgCA6IGRoY3dn QGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCj4+PiBPYmpldCA6IFtkaGN3Z10gQWRv cHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2DQo+Pj4NCj4+ PiBIaSBhbGwsDQo+Pj4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEgcmVzdWx0IG9mIHRoZSBkaXNjdXNz aW9uIHdlIGhhZCBkdXJpbmcgbGFzdCBtZWV0aW5nIGluDQo+Pj4gT3JsYW5kby4gV2UgaGF2ZSB2 ZXJ5IHByb2R1Y3RpdmUgZGlzY3Vzc2lvbiBhYm91dCBJUHY0IGhvc3RzDQo+Pj4gY29uZmlndXJh dGlvbiBpbiBJUHY2LW9ubHkgbmV0d29yay4gQWZ0ZXIgd2UgcmVhY2hlZCB3aGF0IGxvb2tlZCBs aWtlIGENCj4+PiBjb25zZW5zdXMgaW4gdGhlIG1lZXRpbmcgcm9vbSwgY291cGxlIGZvbGtzIHZv bHVudGVlcmVkIHRvIHdyaXRlIGRvd24NCj4+PiB0aGUgZHJhZnQgdGhhdCBzdW1tYXJpemVzIHRo YXQgcGVyY2VpdmVkIGNvbnNlbnN1cy4gVGhpcyBkcmFmdCBpcyBhDQo+Pj4gcHJvZHVjdCBvZiB0 aGlzIGVmZm9ydC4NCj4+Pg0KPj4+IEFzIHJlcXVlc3RlZCBieSBhdXRob3JzLCB3ZSBhcmUgYW5u b3VuY2luZyBhZG90aW9uIGNhbGwgb24NCj4+PiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXIt ZGhjcHY2LTAxLiBUaGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvDQo+Pj4gY29uZmlybSB3 aGV0aGVyIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIHdvcmsgYXMgREhDIFdH DQo+Pj4gZHJhZnQuIFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Ig b2YgdGhlIGFkb3B0aW9uIGJ5DQo+Pj4gcmVwbHlpbmcgdG8gdGhpcyBtYWlsLiBJZiB5b3UgYXJl IG5vdCBpbiBmYXZvciwgcGxlYXNlIGFsc28gc3RhdGUgeW91cg0KPj4+IG9iamVjdGlvbnMgaW4g eW91ciByZXNwb25zZS4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29tcGxldGUgb24gMjAxMy0N Cj4wNC0NCj4+PiAxNy4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4gQmVybmllICYgVG9tZWsNCj4+ Pg0KPj4+IE9uIDAzLjA0LjIwMTMgMTk6MjAsIE1hcmNpbiBTaW9kZWxza2kgd3JvdGU6DQo+Pj4+ IEluIHRoZSBuYW1lIG9mIGF1dGhvcnMgb2YgZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRo Y3B2NiBJIGFtDQo+YXNraW5nDQo+Pj4+IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGJ5 IERIQyBXRy4NCj4+Pj4NCj4+Pj4gVGhlIGxhdGVzdCB2ZXJzaW9uICgtMDEpIGlzIGF2YWlsYWJs ZSBoZXJlOg0KPj4+Pg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LQ0KPj4+IDAxLnR4dA0KPj4+PiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2 LTAxDQo+Pj4+DQo+Pj4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIHdoZXJl YnkgSVB2NCBjbGllbnQgb2J0YWlucyBpdHMNCj4+Pj4gY29uZmlndXJhdGlvbiBmcm9tIHRoZSBE SENQdjQgc2VydmVyIHNlcGFyYXRlZCBmcm9tIHRoZSBjbGllbnQgYnkgSVB2Ni0NCj4+Pj4gb25s eSBuZXR3b3JrIGhhdmluZyBESENQdjYgc2VydmljZS4gVGhpcyBtZWNoYW5pc20gaXMgZnJlcXVl bnRseQ0KPj4+PiByZWZlcnJlZCBhcyAiREhDUHY0LW92ZXItREhDUHY2Ii4NCj4+Pj4NCj4+Pj4g VGhlIERIQ1B2NCBjbGllbnQncyByZXF1ZXN0IGlzIGNhcnJpZWQgaW4gdGhlIG5ld2x5IGRlZmlu ZWQgREhDUHY2DQo+Pj4+IG1lc3NhZ2VzL29wdGlvbiB0by9mcm9tIHRoZSBzZXJ2ZXIgYW5kIGNh biBiZSBzZW50IGVpdGhlciB0aHJvdWdoIGENCj4+Pj4gcmVsYXkgb3IgZGlyZWN0bHkuDQo+Pj4+ DQo+Pj4+IENoZWVycywNCj4+Pj4gTWFyY2luDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IGRoY3dnIG1h aWxpbmcgbGlzdA0KPj4+PiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+Pj4NCj4+ Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+Pj4gZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGll dGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBk aGN3ZyBtYWlsaW5nIGxpc3QNCj4+IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9y Zz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxp bmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29m dHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0K --_000_CEB7ADD2C5444CFFBFFA6404F726C7C2ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkkgYWdyZWUgd2l0aCBNZWQuIEluIHJlYWxpdHksIGl0IGlzIGhpZ2hseSB1bmxpa2VseSB0 aGF0IGVhY2ggYW5kIGV2ZXJ5IERoY3B2NCBvcHRpb24gd291bGQgYmUgbmVlZGVkIGZvciBhbiBp cHY2IG9ubHkgaG9zdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFuZCB0aGUgb25l cyB0aGF0IGFyZSByZWFsbHkgbmVlZGVkLCAmbmJzcDt3b3VsZCBiZXR0ZXIgbW92ZSB0byBkaGN2 cHY2IHNvb25lciB0aGFuIGxhdGVyLiBJdCB3b3VsZCBiZSBwcnVkZW50IGZvciB1cyB0byBkbyBm aW5kIHRoZSBkZWx0YSBpbnN0ZWFkIG9mIGNhcnJ5aW5nIG92ZXIgdGhlIGxlZ2FjeSBhbmQgZ2V0 dGluZyB0aGUgcmVsZXZhbnQgb25lcyBmaXhlZC4gT3IgaGFzIHRoYXQgd29yayBiZWVuIGRvbmUg YWxyZWFkeT8mbmJzcDs8YnI+DQo8YnI+DQpDaGVlcnMsDQo8ZGl2PlJhaml2PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZW50IGZyb20gbXkgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRp dj48YnI+DQpPbiBBcHIgMTUsIDIwMTMsIGF0IDU6MzYgQU0sICZxdW90OzxhIGhyZWY9Im1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxtZXRhIG5hbWU9 IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSki Pg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYg OSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVw dCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ug c2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFpIFN1biBbPGEgaHJlZj0ibWFp bHRvOnN1bnFpLmNzbmV0LnRodUBnbWFpbC5jb20iPm1haWx0bzpzdW5xaS5jc25ldC50aHVAZ21h aWwuY29tPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAxNSBhdnJpbCAy MDEzIDExOjAwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09M Tjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5k aGN3Z0BpZXRmLm9yZzwvYT47IFNvZnR3aXJlcyAoPGEgaHJlZj0ibWFpbHRvOnNvZnR3aXJlc0Bp ZXRmLm9yZyI+c29mdHdpcmVzQGlldGYub3JnPC9hPik8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFJlOiBbZGhjd2ddIEFkb3B0aW9uIGNhbGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVy LWRoY3B2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EZWFyIE1lZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGNlcHQgJnF1b3Q7SVB2NCBhZGRyZXNz aW5nJnF1b3Q7LXJlbGF0ZWQgY29uZmlndXJhdGlvbiwgd2hhdCBhZGRpdGlvbmFsIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVycyBjYW4gYmUgcHJvdmlzaW9uZWQgd2l0aCBESENQdjQgYW5kIG5vdCB3 aXRoIERIQ1B2Nj88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPltRaV0gVGhlcmUgYXJlIG92ZXIgMjAwIERIQ1B2NCBvcHRpb25zIHRo YXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByb3ZpZGUgSVB2NCBzZXJ2aWNlcy4gSW4gdGhlIHBlcmlv ZCBvZiB0cmFuc2l0aW9uLA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5bTWVkXSBUaGUgcXVlc3Rpb24gaXMgbm90IGhvdyBtYW55IGRoY3B2NCBl eGlzdCwgYnV0IHdoaWNoIG9uZXMgYXJlIHJlYWxseSBuZWVkZWQgd2hlbiB0aGUgaG9zdCBpcyBJ UHY2LWVuYWJsZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+c29tZSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgc2Vydmlj ZXMgbWF5IHJlbWFpbiBpbiBJUHY0IGZvciBzb21lIHRpbWUsIHdoaWxlIGVuZCB1c2VycyBtYXkg ZGVtYW5kIHRoZXNlIElQdjQgc2VydmljZXMgdG8gYmUgZGVsaXZlcmVkIG92ZXIgSVB2Ni4NCjwv c3Bhbj5UaGUgcmVxdWlyZWQgaW5mbyBtYXkgYmUgbW9yZSB0aGFuIElQdjQgYWRkcmVzc2VzIChw b3J0IHNldCkuIEFzIGZvciBleGFtcGxlcywgSU1ITywgU0lQIHNlcnZlciBvcHRpb24gYW5kDQo8 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRd IFRoaXMgaXMgZG9hYmxlIHVzaW5nIG9wdGlvbiAyMS4gVGhlIG5hbWUgY2FuIGJlIHJlc29sdmVk IHRvIGFuIElQdjYgb3IgYW4gSVB2NCBhZGRyZXNzLiBOb3RoaW5nIHByZXZlbnQgZnJvbSBkb2lu ZyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5UUCBzZXJ2ZXIgb3B0 aW9uIGFyZSBwb3RlbnRpYWwgY3VzdG9tZXJzIGZvciB0aGlzIHVzYWdlLjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIFRoaXMg aXMgZG9hYmxlIHVzaW5nIGRoY3B2Ni4gV2h5IHRoZSB1c2UgZGhwdjQtb3Zlci1kaGNwdjYgaXMg YSBtdXN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgbWF5IGJl IG1vcmUsIGJlY2F1c2UgZGVtYW5kcyBhcmUgYXJpc2luZyB3aXRoIHRpbWUgZ29pbmcgb24uPHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W01lZF0gSeKAmW0gc3RpbGwgbm90IHNlZWluZyBhbnkgcGFydGljdWxhciBkZW1hbmQgd2hpY2gg Y2Fubm90IGJlIGhvbm9yZWQgdXNpbmcgZGhjcHY2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGluIHRoZSBmdXR1cmUsIGFuIElQdjYtZW5hYmxl ZCBub2RlIHdpbGwgcmVxdWlyZSB0byByZXRyaWV2ZSBjb25maWd1cmF0aW9uIHVzaW5nIERIQ1B2 NC1vdmVyLURIQ1B2NiBhbmQgbm90IGRpcmVjdGx5IHVzaW5nIERIQ1B2Nj88bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltRaV0gV2Ug YXJlIHRhbGtpbmcgYWJvdXQgSVB2Ni1lbmFibGVkIG5vZGUgaW4gSVB2NC9JUHY2IHRyYW5zaXRp b24gcGVyaW9kLCB3aGVuIElQdjQgYW5kIElQdjYgc2VydmljZXMgYXJlIGNvZXhpc3RlZC4gVXNp bmcgREhDUHY0LW92ZXItREhDUHY2IGNhbiBndWFyYW50ZWUgYWxsIERIQ1AtYmFzZWQgc2Vydmlj ZXMgdG8gYmUgY29uZmlndXJlZCBjb3JyZWN0bHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIFdoYXQgYXJlIHRob3NlIHNlcnZpY2VzPyBXaHkg dGhvc2Ugc2VydmljZXMgY2Fubm90IGJlIGNvbmZpZ3VyZWQgdXNpbmcgREhDUHY2PyBCZWZvcmUg ZGVzaWduaW5nIGEgc29sdXRpb24sIHdlIG5lZWQgdW5kZXJzdGFuZCB0aGUgcmVxdWlyZW1lbnRz IGFuZA0KIHRoZSBuZWVkcyBmaXJzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2Yg Y291cnNlLCBpbiBJUHY2IG9ubHkgSW50ZXJuZXQgd2hlcmUgdGhlcmUgaXMgbm8gZGVtYW5kIGZv ciBJUHY0IHNlcnZpY2VzLCB3ZSBzaG91bGQgdXNlIERIQ1B2Ni4gQnV0IERIQ1B2NC1vdmVyLURI Q1B2NiBjYW4gYWxzbyB3b3JrIGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0g4oCmIGV4Y2VwdCB0aGF0IGRoY3B2NC1vdmVy LWRoY3B2NiBpbnRyb2R1Y2VzIG1vcmUgY29tcGxleGl0eSBmb3Igbm90IG9idmlvdXMgcmVhc29u cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UWk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo ZWVycyw8YnI+DQpNZWQ8YnI+DQo8YnI+DQomZ3Q7LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtEZSZuYnNw OzogUWkgU3VuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN1bnFpLnRodUBnbWFpbC5jb20iPnN1 bnFpLnRodUBnbWFpbC5jb208L2E+XTxicj4NCiZndDtFbnZvecOpJm5ic3A7OiBsdW5kaSAxNSBh dnJpbCAyMDEzIDA3OjU2PGJyPg0KJmd0O8OAJm5ic3A7OiBCT1VDQURBSVIgTW9oYW1lZCBPTE5D L09MTjxicj4NCiZndDtDYyZuYnNwOzogVG9tZWsgTXJ1Z2Fsc2tpOyA8YSBocmVmPSJtYWlsdG86 ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjsgU29mdHdpcmVzICg8YSBocmVmPSJt YWlsdG86c29mdHdpcmVzQGlldGYub3JnIj5zb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+KTxicj4NCiZn dDtPYmpldCZuYnNwOzogUmU6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1k aGMtZGhjcHY0LW92ZXItZGhjcHY2PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O0RlYXIgTWVkLDxicj4NCiZn dDs8YnI+DQomZ3Q7VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBIZXJlIGlzIG15IHVuZGVyc3Rh bmRpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDtJTUhPLCBkZWZpbmluZyBvcHRpb25zIGluIERIQ1B2 NiBzZWVtcyB0byBpbnRyb2R1Y2UgbGVzcyBjb21wbGV4aXR5IGluPGJyPg0KJmd0O3Byb3RvY29s LiBIb3dldmVyLCB3ZSBkbyBub3Qga25vdyBmb3Igbm93IHdoaWNoIG9wdGlvbnMgYXJlIG5lZWRl ZCBpbiB0aGU8YnI+DQomZ3Q7ZnV0dXJlLiBJZiB3ZSBoYXZlIHRvIHBvcnQgREhDUHY0IG9wdGlv bnMgaW50byBESENQdjYsIGhvdyBtYW55IHRpbWVzPGJyPg0KJmd0O3Nob3VsZCB3ZSBkbyB0aGUg d29yaz8gTGlrZSBvbmUgbmV3IG9wdGlvbiBwZXIgMiB5ZWFycywgb3IgcmVkZWZpbmluZyBhbGw8 YnI+DQomZ3Q7REhDUHY0IG9wdGlvbnMgaW50byBESENQdjYgYXQgb25lIHRpbWU/IFRoZSBwcm9w b3NlZCBzb2x1dGlvbiB0cmllcyB0bzxicj4NCiZndDthdm9pZCBwb2xsdXRpbmcgdGhlIERIQ1B2 NiBvcHRpb24gc3BhY2UsIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgdHJhbnNpdGlvbjxicj4NCiZn dDtpbiBESENQLjxicj4NCiZndDs8YnI+DQomZ3Q7QW5vdGhlciBwb2ludCBpcyB0aGF0LCBkZWZp bmluZyBvcHRpb24ocykgLyBjb250YWluZXIgd291bGQgcmVxdWlyZSB0aGU8YnI+DQomZ3Q7REhD UHY2IGVuZ2luZSB0byBoYW5kbGUgREhDUHY0IG9wdGlvbnMsIHdoaWNoIHdvdWxkIGludHJvZHVj ZSBtb3JlPGJyPg0KJmd0O2NvbXBsZXhpdHkgdG8gdGhlIGxvZ2ljIGFuZCBpbXBsZW1lbnRhdGlv biBvZiBlbmQgcG9pbnRzLiBUaGUgcHJvcG9zZWQ8YnI+DQomZ3Q7c29sdXRpb24gbGV2ZXJhZ2Vz IHRoZSBESENQdjQgZW5naW5lIGZvciBESENQdjQgbWVzc2FnZXMgLyBvcHRpb25zIGFuZDxicj4N CiZndDtESENQdjYgZW5naW5lIGZvciBESENQdjYgbWVzc2FnZXMgLyBvcHRpb25zLiBUaGUgZW5k IHBvaW50cyB3b3VsZDxicj4NCiZndDtjb21wYXRpYmxlIHRvIGJvdGggREhDUHY0IHByb2Nlc3Mg YW5kIERIQ1B2NiBwcm9jZXNzLiBUaGlzIGlzIG1vcmUgc3VpdGFibGU8YnI+DQomZ3Q7Zm9yIHRo ZSB0cmFuc2l0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7QSB0aGlyZCBjb25zaWRlcmF0aW9uIGlz LCBpbiB0aGUgY2FzZSBvZiBJUHY2IHRyYW5zaXRpb24sIHRoZSBESENQIGNsaWVudDxicj4NCiZn dDsob24gdGhlIHR1bm5lbCBlbmRwb2ludCkgaXMgYm91bmQgdG8gYmUgbW9kaWZpZWQuIFdlIHRo aW5rIGl0IGJldHRlciB0bzxicj4NCiZndDttb2RpZnkgdGhlIGNsaWVudCBjb21wbGV0ZWx5IGZv ciB0aGUgdHJhbnNpdGlvbiBwdXJwb3NlLjxicj4NCiZndDs8YnI+DQomZ3Q7TGFzdCBidXQgbm90 IHRoZSBsZWFzdCwgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGJhc2VkIG9uIHRoZSBESENQdjY8 YnI+DQomZ3Q7aW5mcmFzdHJ1Y3R1cmUsIHdoaWNoIGhhcyBiZWVuIGRlcGxveWVkIGluIG9wZXJh dG9ycycgbmV0d29ya3MuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGUgREhDUHY0IG92ZXIgREhDUHY2 IG1lY2hhbmlzbSBpcyBhbiBhcmNoaXRlY3R1cmFsIGRldmVsb3BtZW50IGZvciBESENQPGJyPg0K Jmd0O3Byb3RvY29sIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgY29uZmlndXJpbmcgSVB2 NCBwYXJhbWV0ZXJzIGFjcm9zczxicj4NCiZndDt0aGUgSVB2NiBuZXR3b3JrLiBXZSB0aGluayBp dCBpcyBpbXBvcnRhbnQgZm9yIHRoZSBESEMgV0cgdG8gd29yayBvbiBpdC48YnI+DQomZ3Q7PGJy Pg0KJmd0O0Jlc3QgUmVnYXJkcyw8YnI+DQomZ3Q7UWkgU3VuPGJyPg0KJmd0OyhTb3JyeSBmb3Ig cmVzZW5kaW5nLCB0cnkgdG8gc3luY2hyb25pemUgd2l0aCBzb2Z0d2lyZSBNTC4uLik8YnI+DQom Z3Q7PGJyPg0KJmd0O09uIDIwMTMtNC0xMiwgYXQgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+5LiL5Y2IPC9zcGFuPjc6NDcsICZsdDs8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBEZWFyIGFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IChJIGNjIHNvZnd0aXJlIGFzIHRoaXMgd29yayBpcyBhbHNvIHJlbGV2YW50IGZvciB0 aGUgd29ya2luZyBncm91cC4pPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGRvIG5vdCBz dXBwb3J0IHRoaXMgd29yayBhcyBpdCBpbmR1Y2VzIG1vcmUgY29tcGxleGl0eSBjb21wYXJlZCB0 byBqdXN0PGJyPg0KJmd0O2RlZmluaW5nIGFkZXF1YXRlIG9wdGlvbiBpbiBkaGNwdjYuIERlZmlu aW5nIG9uZSBjb250YWluZXIgb3IgZmV3IERIQ1B2Njxicj4NCiZndDtvcHRpb25zIGlzIG11Y2gg bW9yZSBzaW1wbGVyIHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNoLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7IE1lZDxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0 OyBEZSA6IDxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnIj5kaGN3Zy1ib3Vu Y2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2VzQGll dGYub3JnIj5kaGN3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydDxicj4NCiZndDtk ZTxicj4NCiZndDsmZ3Q7Jmd0OyBUb21layBNcnVnYWxza2k8YnI+DQomZ3Q7Jmd0OyZndDsgRW52 b3nDqSA6IG1lcmNyZWRpIDMgYXZyaWwgMjAxMyAxOTo0MTxicj4NCiZndDsmZ3Q7Jmd0OyDDgCA6 IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyZndDsmZ3Q7IE9iamV0IDogW2RoY3dnXSBBZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LXNjc2tm LWRoYy1kaGNwdjQtb3Zlci1kaGNwdjY8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgSGkgYWxsLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGlzIGRyYWZ0 IGlzIGEgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBkdXJpbmcgbGFzdCBtZWV0aW5n IGluPGJyPg0KJmd0OyZndDsmZ3Q7IE9ybGFuZG8uIFdlIGhhdmUgdmVyeSBwcm9kdWN0aXZlIGRp c2N1c3Npb24gYWJvdXQgSVB2NCBob3N0czxicj4NCiZndDsmZ3Q7Jmd0OyBjb25maWd1cmF0aW9u IGluIElQdjYtb25seSBuZXR3b3JrLiBBZnRlciB3ZSByZWFjaGVkIHdoYXQgbG9va2VkIGxpa2Ug YTxicj4NCiZndDsmZ3Q7Jmd0OyBjb25zZW5zdXMgaW4gdGhlIG1lZXRpbmcgcm9vbSwgY291cGxl IGZvbGtzIHZvbHVudGVlcmVkIHRvIHdyaXRlIGRvd248YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIGRy YWZ0IHRoYXQgc3VtbWFyaXplcyB0aGF0IHBlcmNlaXZlZCBjb25zZW5zdXMuIFRoaXMgZHJhZnQg aXMgYTxicj4NCiZndDsmZ3Q7Jmd0OyBwcm9kdWN0IG9mIHRoaXMgZWZmb3J0Ljxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBcyByZXF1ZXN0ZWQgYnkgYXV0aG9ycywgd2UgYXJl IGFubm91bmNpbmcgYWRvdGlvbiBjYWxsIG9uPGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LXNjc2tm LWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYtMDEuIFRoaXMgY2FsbCBpcyBiZWluZyBpbml0aWF0ZWQg dG88YnI+DQomZ3Q7Jmd0OyZndDsgY29uZmlybSB3aGV0aGVyIHRoZXJlIGlzIFdHIGNvbnNlbnN1 cyB0byBhZG9wdCB0aGlzIHdvcmsgYXMgREhDIFdHPGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LiBQ bGVhc2Ugc3RhdGUgd2hldGhlciBvciBub3QgeW91J3JlIGluIGZhdm9yIG9mIHRoZSBhZG9wdGlv biBieTxicj4NCiZndDsmZ3Q7Jmd0OyByZXBseWluZyB0byB0aGlzIG1haWwuIElmIHlvdSBhcmUg bm90IGluIGZhdm9yLCBwbGVhc2UgYWxzbyBzdGF0ZSB5b3VyPGJyPg0KJmd0OyZndDsmZ3Q7IG9i amVjdGlvbnMgaW4geW91ciByZXNwb25zZS4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29tcGxl dGUgb24gMjAxMy08YnI+DQomZ3Q7MDQtPGJyPg0KJmd0OyZndDsmZ3Q7IDE3Ljxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsmZ3Q7Jmd0OyBCZXJu aWUgJmFtcDsgVG9tZWs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gMDMu MDQuMjAxMyAxOToyMCwgTWFyY2luIFNpb2RlbHNraSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IEluIHRoZSBuYW1lIG9mIGF1dGhvcnMgb2YgZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVy LWRoY3B2NiBJIGFtPGJyPg0KJmd0O2Fza2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZm9yIGFk b3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYnkgREhDIFdHLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBsYXRlc3QgdmVyc2lvbiAoLTAxKSBpcyBhdmFpbGFi bGUgaGVyZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zY3NrZi1kaGMt ZGhjcHY0LW92ZXItZGhjcHY2LSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni08L2E+ PGJyPg0KJmd0OyZndDsmZ3Q7IDAxLnR4dDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRo Y3B2Ni0wMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMTwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hh bmlzbSB3aGVyZWJ5IElQdjQgY2xpZW50IG9idGFpbnMgaXRzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBjb25maWd1cmF0aW9uIGZyb20gdGhlIERIQ1B2NCBzZXJ2ZXIgc2VwYXJhdGVkIGZyb20gdGhl IGNsaWVudCBieSBJUHY2LTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgb25seSBuZXR3b3JrIGhhdmlu ZyBESENQdjYgc2VydmljZS4gVGhpcyBtZWNoYW5pc20gaXMgZnJlcXVlbnRseTxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgcmVmZXJyZWQgYXMgJnF1b3Q7REhDUHY0LW92ZXItREhDUHY2JnF1b3Q7Ljxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBESENQdjQgY2xp ZW50J3MgcmVxdWVzdCBpcyBjYXJyaWVkIGluIHRoZSBuZXdseSBkZWZpbmVkIERIQ1B2Njxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgbWVzc2FnZXMvb3B0aW9uIHRvL2Zyb20gdGhlIHNlcnZlciBhbmQg Y2FuIGJlIHNlbnQgZWl0aGVyIHRocm91Z2ggYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcmVsYXkg b3IgZGlyZWN0bHkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg Q2hlZXJzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTWFyY2luPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZGhjd2cgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9h Pjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBkaGN3ZyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PGJyPg0KJmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBkaGN3 ZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5v cmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnPC9hPjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZGhjd2cgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaGN3ZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPlNv ZnR3aXJlcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOlNv ZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJl cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+PC9z cGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CEB7ADD2C5444CFFBFFA6404F726C7C2ciscocom_-- From stenc@s-carlsen.dk Mon Apr 15 03:28:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A11A21F8F20 for ; Mon, 15 Apr 2013 03:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAdZqX-fNhPp for ; Mon, 15 Apr 2013 03:28:32 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id A141521F8F03 for ; Mon, 15 Apr 2013 03:28:31 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fefe:16ca]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 42B5D26D4; Mon, 15 Apr 2013 12:28:27 +0200 (CEST) Message-ID: <516BD64B.8000606@s-carlsen.dk> Date: Mon, 15 Apr 2013 12:28:27 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <77D82DCE-2C81-48B4-B4E9-EA30CCC73449@fugue.com> <516A7C4C.8010207@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775146765@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775146765@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------060107090303060504010004" Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 10:28:32 -0000 This is a multi-part message in MIME format. --------------060107090303060504010004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't have the information you ask for. OTOH I have seen this particular question come up in the DHCP-users so often that it looks like a common setup. One possible reason to do so might be separation of responsibilities, not that I think that is the best way but it seems to happen often anyway. On 14/04/13 16:07, Ted Lemon wrote: > On Apr 14, 2013, at 5:52 AM, Sten Carlsen > wrote: >> My first comment is to Figure 1, you have 4 relays. They are all >> placed in the gateways, it may be beneficial to place at least one of >> them away from the gateway to indicate that this is also a valid >> configuration. > > It's certainly a "valid" configuration, but I don't think it's a > common configuration, and I'm trying to describe current practice in > this document, not what you "could" do. For that, you ought to buy > the DHCP Handbook! :) > > Seriously, do you know of common deployments where the relay is > configured that way? Out side of academic experiments, I'm not aware > of any. I've done that as a hack when I wanted to make the relay do > something unusual, but it's always been a temporary measure on the way > to getting the feature into the place where I really want it, not as > an end in itself. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------060107090303060504010004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't have the information you ask for. OTOH I have seen this particular question come up in the DHCP-users so often that it looks like a common setup.

One possible reason to do so might be separation of responsibilities, not that I think that is the best way but it seems to happen often anyway.


On 14/04/13 16:07, Ted Lemon wrote:
On Apr 14, 2013, at 5:52 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
My first comment is to Figure 1, you have 4 relays. They are all placed in the gateways, it may be beneficial to place at least one of them away from the gateway to indicate that this is also a valid configuration.

It's certainly a "valid" configuration, but I don't think it's a common configuration, and I'm trying to describe current practice in this document, not what you "could" do.   For that, you ought to buy the DHCP Handbook!   :)

Seriously, do you know of common deployments where the relay is configured that way?   Out side of academic experiments, I'm not aware of any.   I've done that as a hack when I wanted to make the relay do something unusual, but it's always been a temporary measure on the way to getting the feature into the place where I really want it, not as an end in itself.


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------060107090303060504010004-- From simon.perreault@viagenie.ca Mon Apr 15 05:17:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634DD21F9385 for ; Mon, 15 Apr 2013 05:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqVM6sdMQpSH for ; Mon, 15 Apr 2013 05:17:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CF38721F9381 for ; Mon, 15 Apr 2013 05:17:24 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:9f7:2bee:3b7e:60c2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2901B40402 for ; Mon, 15 Apr 2013 08:17:24 -0400 (EDT) Message-ID: <516BF023.5090707@viagenie.ca> Date: Mon, 15 Apr 2013 14:18:43 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:17:25 -0000 Le 2013-04-15 12:02, Rajiv Asati (rajiva) a écrit : > I agree with Med. In reality, it is highly unlikely that each and every > Dhcpv4 option would be needed for an ipv6 only host. Sure we can expect that today with the information we have at our disposal. But what will we do if in the future the situation changes, for whatever unanticipated reason, and we need more IPv4 options? Assuming we won't need more makes it very easy to paint ourselves into a corner. Simon From mohamed.boucadair@orange.com Mon Apr 15 05:57:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A989B21F84B5; Mon, 15 Apr 2013 05:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzP49PX0r9TO; Mon, 15 Apr 2013 05:57:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B824721F8464; Mon, 15 Apr 2013 05:57:38 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CC64022C4FA; Mon, 15 Apr 2013 14:57:37 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 873DC27C06E; Mon, 15 Apr 2013 14:57:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 15 Apr 2013 14:57:37 +0200 From: To: Simon Perreault , "dhcwg@ietf.org" Date: Mon, 15 Apr 2013 14:57:36 +0200 Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac450zPa+M9NPtugRJKWH3rA1dxKDAAA3v2Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C586@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> <516BF023.5090707@viagenie.ca> In-Reply-To: <516BF023.5090707@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.15.113320 Cc: "Softwires \(softwires@ietf.org\)" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:57:39 -0000 Hi Simon, (cced softwire ML as this topic is of the interest of the wg too. This draf= t cannot be discussed without having the problem space to solve in mind) With all due respect, complexifying the design because of a speculated need= of IPv4-centric options in the future is not a valid argument IMHO. RFC6333 is a typical example of a solution which shows we don't need at all= DHCPv4 to offer IPv4 service continuity. As discussed in http://datatracker.ietf.org/doc/draft-ietf-softwire-unified= -cpe/, very few parameters in addition to DS-Lite ones are needed to be con= figured to support MAP and LW4over6. Those few parameters can be packaged i= n one single DHCPv6 option and we are done. Cheers, Med >-----Message d'origine----- >De=A0: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e >Simon Perreault >Envoy=E9=A0: lundi 15 avril 2013 14:19 >=C0=A0: dhcwg@ietf.org >Objet=A0: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4- >over-dhcpv6 > >Le 2013-04-15 12:02, Rajiv Asati (rajiva) a =E9crit : >> I agree with Med. In reality, it is highly unlikely that each and every >> Dhcpv4 option would be needed for an ipv6 only host. > >Sure we can expect that today with the information we have at our >disposal. But what will we do if in the future the situation changes, >for whatever unanticipated reason, and we need more IPv4 options? >Assuming we won't need more makes it very easy to paint ourselves into a >corner. > >Simon >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 15 05:58:23 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DDE21F84B5; Mon, 15 Apr 2013 05:58:23 -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 1gbcFS8H55TJ; Mon, 15 Apr 2013 05:58:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D2DF621F8464; Mon, 15 Apr 2013 05:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39409; q=dns/txt; s=iport; t=1366030701; x=1367240301; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=F+ZNUS9CXMxYXd1O7/3YXNirafNB1bp8AZhWOnHVgUw=; b=eC8KrA5P8gHzJwkmIQtwamNXE5tBB/pn9C09+ak3aBy8XLxqowiTiCjK Dq4XLF1Ljw/ODeS4U3VtyfzScZl1yHBss5btoooXue2EWEqXie6c4y/uM cPQL6dNLbYE5xyd33YkW/kq5KEk5IXA34xKFYr69u5WLv+TmQS1Hj9ABV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAFr4a1GtJXG+/2dsb2JhbABQgkJENoMwtRoBiDUNfBZ0gh8BAQEEAQEBIAo6BwsQAgEGAhggBwMCAgIfBgsUEQIEDgUJEodnAw8MjiObBIgXDYldjESBIYEXFwQGAYIuMmEDkn6CJIFjgSGKVIUcgwuBcw X-IronPort-AV: E=Sophos;i="4.87,476,1363132800"; d="scan'208,217";a="198828489" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 15 Apr 2013 12:58:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3FCwJFI025732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 12:58:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 07:58:19 -0500 From: "Bernie Volz (volz)" To: "Rajiv Asati (rajiva)" Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOcBsikXiEMvOkEW/KD2gVeCSvpjXPkzS Date: Mon, 15 Apr 2013 12:58:19 +0000 Message-ID: <8B041637-92C7-439F-99C5-692193ECF101@cisco.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8B04163792C7439F99C5692193ECF101ciscocom_" MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:58:23 -0000 --_000_8B04163792C7439F99C5692193ECF101ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgbXVzdCBhbHNvIGNvbnNpZGVyIGFsbCBvZiB0aGUgb3RoZXIgaW5mcmFzdHJ1Y3R1cmUgdGhh dCBhbHJlYWR5IGV4aXN0cyBmb3IgREhDUHY0IHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNoIGlz IGFibGUgdG8gbGV2ZXJhZ2UgLSBmYWlsb3ZlciwgZG5zIHVwZGF0ZXMsIGxlYXNlcXVlcnksIGV0 Yy4gQWxsIG9mIHRoaXMgd291bGQgcmVxdWlyZSBzaWduaWZpY2FudCByZXdvcmsgaWYgdGhlc2Ug dGhpbmdzIHdlcmUgcGFydCBvZiBESENQdjYuIEJ5IHVzaW5nIHRoZSBleGlzdGluZyB2NCBzZXJ2 ZXIgZW5naW5lIChleGNlcHQgZm9yIGluamVjdGluZyBhbmQgc2VuZGluZyBwYWNrZXRzKSwgYWxs IHRoYXQgaW5mcmFzdHJ1Y3R1cmUgY29tZXMgZm9yIGZyZWUuDQoNCllvdSBhbHNvIGdldCBzaW1p bGFyIGJlbmVmaXRzIG9uIHRoZSBjbGllbnQgc2lkZSBzaW5jZSB0aGUgREhDUHY0IGNsaWVudCBj b2RlIGlzIGJlaW5nIHVzZWQgcHJldHR5IG11Y2ggaW50YWN0Lg0KDQotIEJlcm5pZQ0KDQpPbiBB cHIgMTUsIDIwMTMsIGF0IDY6MDMgQU0sICJSYWppdiBBc2F0aSAocmFqaXZhKSIgPHJhaml2YUBj aXNjby5jb208bWFpbHRvOnJhaml2YUBjaXNjby5jb20+PiB3cm90ZToNCg0KSSBhZ3JlZSB3aXRo IE1lZC4gSW4gcmVhbGl0eSwgaXQgaXMgaGlnaGx5IHVubGlrZWx5IHRoYXQgZWFjaCBhbmQgZXZl cnkgRGhjcHY0IG9wdGlvbiB3b3VsZCBiZSBuZWVkZWQgZm9yIGFuIGlwdjYgb25seSBob3N0Lg0K DQpBbmQgdGhlIG9uZXMgdGhhdCBhcmUgcmVhbGx5IG5lZWRlZCwgIHdvdWxkIGJldHRlciBtb3Zl IHRvIGRoY3ZwdjYgc29vbmVyIHRoYW4gbGF0ZXIuIEl0IHdvdWxkIGJlIHBydWRlbnQgZm9yIHVz IHRvIGRvIGZpbmQgdGhlIGRlbHRhIGluc3RlYWQgb2YgY2Fycnlpbmcgb3ZlciB0aGUgbGVnYWN5 IGFuZCBnZXR0aW5nIHRoZSByZWxldmFudCBvbmVzIGZpeGVkLiBPciBoYXMgdGhhdCB3b3JrIGJl ZW4gZG9uZSBhbHJlYWR5Pw0KDQpDaGVlcnMsDQpSYWppdg0KDQpTZW50IGZyb20gbXkgUGhvbmUN Cg0KT24gQXByIDE1LCAyMDEzLCBhdCA1OjM2IEFNLCAibW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3Jv dGU6DQoNClJlLSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IFFpIFN1biBbbWFpbHRvOnN1bnFpLmNzbmV0LnRodUBnbWFpbC5jb21dDQpFbnZvecOpIDogbHVu ZGkgMTUgYXZyaWwgMjAxMyAxMTowMA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTg0K Q2MgOiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+OyBTb2Z0d2lyZXMgKHNv ZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPikNCk9iamV0IDogUmU6 IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhj cHY2DQoNCkRlYXIgTWVkLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KRXhjZXB0ICJJUHY0IGFk ZHJlc3NpbmciLXJlbGF0ZWQgY29uZmlndXJhdGlvbiwgd2hhdCBhZGRpdGlvbmFsIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVycyBjYW4gYmUgcHJvdmlzaW9uZWQgd2l0aCBESENQdjQgYW5kIG5vdCB3 aXRoIERIQ1B2Nj8NCg0KW1FpXSBUaGVyZSBhcmUgb3ZlciAyMDAgREhDUHY0IG9wdGlvbnMgdGhh dCBtYXkgYmUgcmVxdWlyZWQgdG8gcHJvdmlkZSBJUHY0IHNlcnZpY2VzLiBJbiB0aGUgcGVyaW9k IG9mIHRyYW5zaXRpb24sDQpbTWVkXSBUaGUgcXVlc3Rpb24gaXMgbm90IGhvdyBtYW55IGRoY3B2 NCBleGlzdCwgYnV0IHdoaWNoIG9uZXMgYXJlIHJlYWxseSBuZWVkZWQgd2hlbiB0aGUgaG9zdCBp cyBJUHY2LWVuYWJsZWQuDQoNCg0Kc29tZSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgc2VydmljZXMg bWF5IHJlbWFpbiBpbiBJUHY0IGZvciBzb21lIHRpbWUsIHdoaWxlIGVuZCB1c2VycyBtYXkgZGVt YW5kIHRoZXNlIElQdjQgc2VydmljZXMgdG8gYmUgZGVsaXZlcmVkIG92ZXIgSVB2Ni4gVGhlIHJl cXVpcmVkIGluZm8gbWF5IGJlIG1vcmUgdGhhbiBJUHY0IGFkZHJlc3NlcyAocG9ydCBzZXQpLiBB cyBmb3IgZXhhbXBsZXMsIElNSE8sIFNJUCBzZXJ2ZXIgb3B0aW9uIGFuZA0KW01lZF0gVGhpcyBp cyBkb2FibGUgdXNpbmcgb3B0aW9uIDIxLiBUaGUgbmFtZSBjYW4gYmUgcmVzb2x2ZWQgdG8gYW4g SVB2NiBvciBhbiBJUHY0IGFkZHJlc3MuIE5vdGhpbmcgcHJldmVudCBmcm9tIGRvaW5nIHNvLg0K DQpOVFAgc2VydmVyIG9wdGlvbiBhcmUgcG90ZW50aWFsIGN1c3RvbWVycyBmb3IgdGhpcyB1c2Fn ZS4NCltNZWRdIFRoaXMgaXMgZG9hYmxlIHVzaW5nIGRoY3B2Ni4gV2h5IHRoZSB1c2UgZGhwdjQt b3Zlci1kaGNwdjYgaXMgYSBtdXN0Pw0KDQpUaGVyZSBtYXkgYmUgbW9yZSwgYmVjYXVzZSBkZW1h bmRzIGFyZSBhcmlzaW5nIHdpdGggdGltZSBnb2luZyBvbi4NCltNZWRdIEnigJltIHN0aWxsIG5v dCBzZWVpbmcgYW55IHBhcnRpY3VsYXIgZGVtYW5kIHdoaWNoIGNhbm5vdCBiZSBob25vcmVkIHVz aW5nIGRoY3B2Ni4NCg0KDQpXaHkgaW4gdGhlIGZ1dHVyZSwgYW4gSVB2Ni1lbmFibGVkIG5vZGUg d2lsbCByZXF1aXJlIHRvIHJldHJpZXZlIGNvbmZpZ3VyYXRpb24gdXNpbmcgREhDUHY0LW92ZXIt REhDUHY2IGFuZCBub3QgZGlyZWN0bHkgdXNpbmcgREhDUHY2Pw0KDQpbUWldIFdlIGFyZSB0YWxr aW5nIGFib3V0IElQdjYtZW5hYmxlZCBub2RlIGluIElQdjQvSVB2NiB0cmFuc2l0aW9uIHBlcmlv ZCwgd2hlbiBJUHY0IGFuZCBJUHY2IHNlcnZpY2VzIGFyZSBjb2V4aXN0ZWQuIFVzaW5nIERIQ1B2 NC1vdmVyLURIQ1B2NiBjYW4gZ3VhcmFudGVlIGFsbCBESENQLWJhc2VkIHNlcnZpY2VzIHRvIGJl IGNvbmZpZ3VyZWQgY29ycmVjdGx5Lg0KDQpbTWVkXSBXaGF0IGFyZSB0aG9zZSBzZXJ2aWNlcz8g V2h5IHRob3NlIHNlcnZpY2VzIGNhbm5vdCBiZSBjb25maWd1cmVkIHVzaW5nIERIQ1B2Nj8gQmVm b3JlIGRlc2lnbmluZyBhIHNvbHV0aW9uLCB3ZSBuZWVkIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVt ZW50cyBhbmQgdGhlIG5lZWRzIGZpcnN0Lg0KDQpPZiBjb3Vyc2UsIGluIElQdjYgb25seSBJbnRl cm5ldCB3aGVyZSB0aGVyZSBpcyBubyBkZW1hbmQgZm9yIElQdjQgc2VydmljZXMsIHdlIHNob3Vs ZCB1c2UgREhDUHY2LiBCdXQgREhDUHY0LW92ZXItREhDUHY2IGNhbiBhbHNvIHdvcmsgaW4gdGhp cyBjYXNlLg0KDQpbTWVkXSDigKYgZXhjZXB0IHRoYXQgZGhjcHY0LW92ZXItZGhjcHY2IGludHJv ZHVjZXMgbW9yZSBjb21wbGV4aXR5IGZvciBub3Qgb2J2aW91cyByZWFzb25zLg0KDQpCZXN0IFJl Z2FyZHMsDQpRaQ0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPkRlIDogUWkgU3VuIFttYWlsdG86c3VucWkudGh1QGdtYWlsLmNvbTxtYWlsdG86c3VucWku dGh1QGdtYWlsLmNvbT5dDQo+RW52b3nDqSA6IGx1bmRpIDE1IGF2cmlsIDIwMTMgMDc6NTYNCj7D gCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Q2MgOiBUb21layBNcnVnYWxza2k7IGRo Y3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz47IFNvZnR3aXJlcyAoc29mdHdpcmVz QGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+KQ0KPk9iamV0IDogUmU6IFtkaGN3 Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2DQo+ DQo+DQo+RGVhciBNZWQsDQo+DQo+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBIZXJlIGlzIG15 IHVuZGVyc3RhbmRpbmcuDQo+DQo+SU1ITywgZGVmaW5pbmcgb3B0aW9ucyBpbiBESENQdjYgc2Vl bXMgdG8gaW50cm9kdWNlIGxlc3MgY29tcGxleGl0eSBpbg0KPnByb3RvY29sLiBIb3dldmVyLCB3 ZSBkbyBub3Qga25vdyBmb3Igbm93IHdoaWNoIG9wdGlvbnMgYXJlIG5lZWRlZCBpbiB0aGUNCj5m dXR1cmUuIElmIHdlIGhhdmUgdG8gcG9ydCBESENQdjQgb3B0aW9ucyBpbnRvIERIQ1B2NiwgaG93 IG1hbnkgdGltZXMNCj5zaG91bGQgd2UgZG8gdGhlIHdvcms/IExpa2Ugb25lIG5ldyBvcHRpb24g cGVyIDIgeWVhcnMsIG9yIHJlZGVmaW5pbmcgYWxsDQo+REhDUHY0IG9wdGlvbnMgaW50byBESENQ djYgYXQgb25lIHRpbWU/IFRoZSBwcm9wb3NlZCBzb2x1dGlvbiB0cmllcyB0bw0KPmF2b2lkIHBv bGx1dGluZyB0aGUgREhDUHY2IG9wdGlvbiBzcGFjZSwgd2hpY2ggaXMgbmVjZXNzYXJ5IGZvciB0 cmFuc2l0aW9uDQo+aW4gREhDUC4NCj4NCj5Bbm90aGVyIHBvaW50IGlzIHRoYXQsIGRlZmluaW5n IG9wdGlvbihzKSAvIGNvbnRhaW5lciB3b3VsZCByZXF1aXJlIHRoZQ0KPkRIQ1B2NiBlbmdpbmUg dG8gaGFuZGxlIERIQ1B2NCBvcHRpb25zLCB3aGljaCB3b3VsZCBpbnRyb2R1Y2UgbW9yZQ0KPmNv bXBsZXhpdHkgdG8gdGhlIGxvZ2ljIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBlbmQgcG9pbnRzLiBU aGUgcHJvcG9zZWQNCj5zb2x1dGlvbiBsZXZlcmFnZXMgdGhlIERIQ1B2NCBlbmdpbmUgZm9yIERI Q1B2NCBtZXNzYWdlcyAvIG9wdGlvbnMgYW5kDQo+REhDUHY2IGVuZ2luZSBmb3IgREhDUHY2IG1l c3NhZ2VzIC8gb3B0aW9ucy4gVGhlIGVuZCBwb2ludHMgd291bGQNCj5jb21wYXRpYmxlIHRvIGJv dGggREhDUHY0IHByb2Nlc3MgYW5kIERIQ1B2NiBwcm9jZXNzLiBUaGlzIGlzIG1vcmUgc3VpdGFi bGUNCj5mb3IgdGhlIHRyYW5zaXRpb24uDQo+DQo+QSB0aGlyZCBjb25zaWRlcmF0aW9uIGlzLCBp biB0aGUgY2FzZSBvZiBJUHY2IHRyYW5zaXRpb24sIHRoZSBESENQIGNsaWVudA0KPihvbiB0aGUg dHVubmVsIGVuZHBvaW50KSBpcyBib3VuZCB0byBiZSBtb2RpZmllZC4gV2UgdGhpbmsgaXQgYmV0 dGVyIHRvDQo+bW9kaWZ5IHRoZSBjbGllbnQgY29tcGxldGVseSBmb3IgdGhlIHRyYW5zaXRpb24g cHVycG9zZS4NCj4NCj5MYXN0IGJ1dCBub3QgdGhlIGxlYXN0LCB0aGUgcHJvcG9zZWQgc29sdXRp b24gaXMgYmFzZWQgb24gdGhlIERIQ1B2Ng0KPmluZnJhc3RydWN0dXJlLCB3aGljaCBoYXMgYmVl biBkZXBsb3llZCBpbiBvcGVyYXRvcnMnIG5ldHdvcmtzLg0KPg0KPlRoZSBESENQdjQgb3ZlciBE SENQdjYgbWVjaGFuaXNtIGlzIGFuIGFyY2hpdGVjdHVyYWwgZGV2ZWxvcG1lbnQgZm9yIERIQ1AN Cj5wcm90b2NvbCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgZm9yIGNvbmZpZ3VyaW5nIElQdjQg cGFyYW1ldGVycyBhY3Jvc3MNCj50aGUgSVB2NiBuZXR3b3JrLiBXZSB0aGluayBpdCBpcyBpbXBv cnRhbnQgZm9yIHRoZSBESEMgV0cgdG8gd29yayBvbiBpdC4NCj4NCj5CZXN0IFJlZ2FyZHMsDQo+ UWkgU3VuDQo+KFNvcnJ5IGZvciByZXNlbmRpbmcsIHRyeSB0byBzeW5jaHJvbml6ZSB3aXRoIHNv ZnR3aXJlIE1MLi4uKQ0KPg0KPk9uIDIwMTMtNC0xMiwgYXQg5LiL5Y2INzo0NywgPG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ Pg0KPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+DQo+PiBEZWFyIGFsbCwNCj4+DQo+PiAoSSBjYyBzb2Z3 dGlyZSBhcyB0aGlzIHdvcmsgaXMgYWxzbyByZWxldmFudCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAu KQ0KPj4NCj4+IEkgZG8gbm90IHN1cHBvcnQgdGhpcyB3b3JrIGFzIGl0IGluZHVjZXMgbW9yZSBj b21wbGV4aXR5IGNvbXBhcmVkIHRvIGp1c3QNCj5kZWZpbmluZyBhZGVxdWF0ZSBvcHRpb24gaW4g ZGhjcHY2LiBEZWZpbmluZyBvbmUgY29udGFpbmVyIG9yIGZldyBESENQdjYNCj5vcHRpb25zIGlz IG11Y2ggbW9yZSBzaW1wbGVyIHRoYXQgdGhlIHByb3Bvc2VkIGFwcHJvYWNoLg0KPj4NCj4+IENo ZWVycywNCj4+IE1lZA0KPj4NCj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+PiBE ZSA6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZz5dIERlIGxhIHBhcnQNCj5kZQ0KPj4+IFRvbWVrIE1ydWdhbHNraQ0KPj4+IEVudm95w6kg OiBtZXJjcmVkaSAzIGF2cmlsIDIwMTMgMTk6NDENCj4+PiDDgCA6IGRoY3dnQGlldGYub3JnPG1h aWx0bzpkaGN3Z0BpZXRmLm9yZz4NCj4+PiBPYmpldCA6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBv biBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2DQo+Pj4NCj4+PiBIaSBhbGwsDQo+ Pj4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBk dXJpbmcgbGFzdCBtZWV0aW5nIGluDQo+Pj4gT3JsYW5kby4gV2UgaGF2ZSB2ZXJ5IHByb2R1Y3Rp dmUgZGlzY3Vzc2lvbiBhYm91dCBJUHY0IGhvc3RzDQo+Pj4gY29uZmlndXJhdGlvbiBpbiBJUHY2 LW9ubHkgbmV0d29yay4gQWZ0ZXIgd2UgcmVhY2hlZCB3aGF0IGxvb2tlZCBsaWtlIGENCj4+PiBj b25zZW5zdXMgaW4gdGhlIG1lZXRpbmcgcm9vbSwgY291cGxlIGZvbGtzIHZvbHVudGVlcmVkIHRv IHdyaXRlIGRvd24NCj4+PiB0aGUgZHJhZnQgdGhhdCBzdW1tYXJpemVzIHRoYXQgcGVyY2VpdmVk IGNvbnNlbnN1cy4gVGhpcyBkcmFmdCBpcyBhDQo+Pj4gcHJvZHVjdCBvZiB0aGlzIGVmZm9ydC4N Cj4+Pg0KPj4+IEFzIHJlcXVlc3RlZCBieSBhdXRob3JzLCB3ZSBhcmUgYW5ub3VuY2luZyBhZG90 aW9uIGNhbGwgb24NCj4+PiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxLiBU aGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvDQo+Pj4gY29uZmlybSB3aGV0aGVyIHRoZXJl IGlzIFdHIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIHdvcmsgYXMgREhDIFdHDQo+Pj4gZHJhZnQu IFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlIGFkb3B0 aW9uIGJ5DQo+Pj4gcmVwbHlpbmcgdG8gdGhpcyBtYWlsLiBJZiB5b3UgYXJlIG5vdCBpbiBmYXZv ciwgcGxlYXNlIGFsc28gc3RhdGUgeW91cg0KPj4+IG9iamVjdGlvbnMgaW4geW91ciByZXNwb25z ZS4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29tcGxldGUgb24gMjAxMy0NCj4wNC0NCj4+PiAx Ny4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4gQmVybmllICYgVG9tZWsNCj4+Pg0KPj4+IE9uIDAz LjA0LjIwMTMgMTk6MjAsIE1hcmNpbiBTaW9kZWxza2kgd3JvdGU6DQo+Pj4+IEluIHRoZSBuYW1l IG9mIGF1dGhvcnMgb2YgZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NiBJIGFtDQo+ YXNraW5nDQo+Pj4+IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGJ5IERIQyBXRy4NCj4+ Pj4NCj4+Pj4gVGhlIGxhdGVzdCB2ZXJzaW9uICgtMDEpIGlzIGF2YWlsYWJsZSBoZXJlOg0KPj4+ Pg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zY3NrZi1k aGMtZGhjcHY0LW92ZXItZGhjcHY2LQ0KPj4+IDAxLnR4dA0KPj4+PiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxDQo+Pj4+DQo+ Pj4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIHdoZXJlYnkgSVB2NCBjbGll bnQgb2J0YWlucyBpdHMNCj4+Pj4gY29uZmlndXJhdGlvbiBmcm9tIHRoZSBESENQdjQgc2VydmVy IHNlcGFyYXRlZCBmcm9tIHRoZSBjbGllbnQgYnkgSVB2Ni0NCj4+Pj4gb25seSBuZXR3b3JrIGhh dmluZyBESENQdjYgc2VydmljZS4gVGhpcyBtZWNoYW5pc20gaXMgZnJlcXVlbnRseQ0KPj4+PiBy ZWZlcnJlZCBhcyAiREhDUHY0LW92ZXItREhDUHY2Ii4NCj4+Pj4NCj4+Pj4gVGhlIERIQ1B2NCBj bGllbnQncyByZXF1ZXN0IGlzIGNhcnJpZWQgaW4gdGhlIG5ld2x5IGRlZmluZWQgREhDUHY2DQo+ Pj4+IG1lc3NhZ2VzL29wdGlvbiB0by9mcm9tIHRoZSBzZXJ2ZXIgYW5kIGNhbiBiZSBzZW50IGVp dGhlciB0aHJvdWdoIGENCj4+Pj4gcmVsYXkgb3IgZGlyZWN0bHkuDQo+Pj4+DQo+Pj4+IENoZWVy cywNCj4+Pj4gTWFyY2luDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IGRoY3dnIG1haWxpbmcgbGlzdA0K Pj4+PiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+Pj4NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZGhjd2cgbWFp bGluZyBsaXN0DQo+Pj4gZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBkaGN3ZyBtYWlsaW5n IGxpc3QNCj4+IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhj d2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYu b3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmc8bWFpbHRv OmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aGN3Zw0K --_000_8B04163792C7439F99C5692193ECF101ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PldlIG11c3QgYWxzbyBjb25zaWRlciBhbGwgb2YgdGhlIG90aGVyIGluZnJhc3RydWN0dXJl IHRoYXQgYWxyZWFkeSBleGlzdHMgZm9yIERIQ1B2NCB0aGF0IHRoZSBwcm9wb3NlZCBhcHByb2Fj aCBpcyBhYmxlIHRvIGxldmVyYWdlIC0gZmFpbG92ZXIsIGRucyB1cGRhdGVzLCBsZWFzZXF1ZXJ5 LCBldGMuIEFsbCBvZiB0aGlzIHdvdWxkIHJlcXVpcmUgc2lnbmlmaWNhbnQgcmV3b3JrIGlmIHRo ZXNlIHRoaW5ncyB3ZXJlIHBhcnQgb2YgREhDUHY2Lg0KIEJ5IHVzaW5nIHRoZSBleGlzdGluZyB2 NCBzZXJ2ZXIgZW5naW5lIChleGNlcHQgZm9yIGluamVjdGluZyBhbmQgc2VuZGluZyBwYWNrZXRz KSwgYWxsIHRoYXQgaW5mcmFzdHJ1Y3R1cmUgY29tZXMgZm9yIGZyZWUuICZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91IGFsc28gZ2V0IHNpbWlsYXIgYmVuZWZpdHMgb24g dGhlIGNsaWVudCBzaWRlIHNpbmNlIHRoZSBESENQdjQgY2xpZW50IGNvZGUgaXMgYmVpbmcgdXNl ZCBwcmV0dHkgbXVjaCBpbnRhY3QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIEJl cm5pZTwvZGl2Pg0KPGRpdj48YnI+DQpPbiBBcHIgMTUsIDIwMTMsIGF0IDY6MDMgQU0sICZxdW90 O1Jhaml2IEFzYXRpIChyYWppdmEpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmFqaXZhQGNp c2NvLmNvbSI+cmFqaXZhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5JIGFncmVlIHdpdGggTWVk LiBJbiByZWFsaXR5LCBpdCBpcyBoaWdobHkgdW5saWtlbHkgdGhhdCBlYWNoIGFuZCBldmVyeSBE aGNwdjQgb3B0aW9uIHdvdWxkIGJlIG5lZWRlZCBmb3IgYW4gaXB2NiBvbmx5IGhvc3QuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbmQgdGhlIG9uZXMgdGhhdCBhcmUgcmVhbGx5IG5l ZWRlZCwgJm5ic3A7d291bGQgYmV0dGVyIG1vdmUgdG8gZGhjdnB2NiBzb29uZXIgdGhhbiBsYXRl ci4gSXQgd291bGQgYmUgcHJ1ZGVudCBmb3IgdXMgdG8gZG8gZmluZCB0aGUgZGVsdGEgaW5zdGVh ZCBvZiBjYXJyeWluZyBvdmVyIHRoZSBsZWdhY3kgYW5kIGdldHRpbmcgdGhlIHJlbGV2YW50IG9u ZXMgZml4ZWQuIE9yIGhhcyB0aGF0IHdvcmsgYmVlbiBkb25lIGFscmVhZHk/Jm5ic3A7PGJyPg0K PGJyPg0KQ2hlZXJzLA0KPGRpdj5SYWppdjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ U2VudCBmcm9tIG15IFBob25lPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gQXByIDE1LCAy MDEzLCBhdCA1OjM2IEFNLCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290 aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRl IGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzFGNDk3RDsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0 aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5SZS0s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBRaSBTdW4gWzxhIGhyZWY9Im1haWx0bzpzdW5xaS5jc25ldC50aHVA Z21haWwuY29tIj5tYWlsdG86c3VucWkuY3NuZXQudGh1QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTUgYXZyaWwgMjAxMyAxMTowMDxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+OyBT b2Z0d2lyZXMgKDxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmciPnNvZnR3aXJlc0Bp ZXRmLm9yZzwvYT4pPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW2RoY3dnXSBBZG9wdGlv biBjYWxsIG9uIGRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBNZWQsPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2VlIGlubGlu ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RXhjZXB0ICZxdW90O0lQdjQgYWRkcmVzc2luZyZxdW90Oy1yZWxhdGVkIGNv bmZpZ3VyYXRpb24sIHdoYXQgYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgY2Fu IGJlIHByb3Zpc2lvbmVkIHdpdGggREhDUHY0IGFuZCBub3Qgd2l0aCBESENQdjY/PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bUWld IFRoZXJlIGFyZSBvdmVyIDIwMCBESENQdjQgb3B0aW9ucyB0aGF0IG1heSBiZSByZXF1aXJlZCB0 byBwcm92aWRlIElQdjQgc2VydmljZXMuIEluIHRoZSBwZXJpb2Qgb2YgdHJhbnNpdGlvbiwNCjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0g VGhlIHF1ZXN0aW9uIGlzIG5vdCBob3cgbWFueSBkaGNwdjQgZXhpc3QsIGJ1dCB3aGljaCBvbmVz IGFyZSByZWFsbHkgbmVlZGVkIHdoZW4gdGhlIGhvc3QgaXMgSVB2Ni1lbmFibGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPnNvbWUgc2VydmljZSBwcm92aWRlcnMgYW5kIHNlcnZpY2VzIG1heSByZW1haW4gaW4gSVB2 NCBmb3Igc29tZSB0aW1lLCB3aGlsZSBlbmQgdXNlcnMgbWF5IGRlbWFuZCB0aGVzZSBJUHY0IHNl cnZpY2VzIHRvIGJlIGRlbGl2ZXJlZCBvdmVyIElQdjYuDQo8L3NwYW4+VGhlIHJlcXVpcmVkIGlu Zm8gbWF5IGJlIG1vcmUgdGhhbiBJUHY0IGFkZHJlc3NlcyAocG9ydCBzZXQpLiBBcyBmb3IgZXhh bXBsZXMsIElNSE8sIFNJUCBzZXJ2ZXIgb3B0aW9uIGFuZA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBUaGlzIGlzIGRvYWJsZSB1c2lu ZyBvcHRpb24gMjEuIFRoZSBuYW1lIGNhbiBiZSByZXNvbHZlZCB0byBhbiBJUHY2IG9yIGFuIElQ djQgYWRkcmVzcy4gTm90aGluZyBwcmV2ZW50IGZyb20gZG9pbmcgc28uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5OVFAgc2VydmVyIG9wdGlvbiBhcmUgcG90ZW50aWFsIGN1 c3RvbWVycyBmb3IgdGhpcyB1c2FnZS48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBUaGlzIGlzIGRvYWJsZSB1c2luZyBkaGNw djYuIFdoeSB0aGUgdXNlIGRocHY0LW92ZXItZGhjcHY2IGlzIGEgbXVzdD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIG1heSBiZSBtb3JlLCBiZWNhdXNlIGRlbWFu ZHMgYXJlIGFyaXNpbmcgd2l0aCB0aW1lIGdvaW5nIG9uLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIEnigJltIHN0aWxsIG5v dCBzZWVpbmcgYW55IHBhcnRpY3VsYXIgZGVtYW5kIHdoaWNoIGNhbm5vdCBiZSBob25vcmVkIHVz aW5nIGRoY3B2Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoeSBpbiB0aGUgZnV0dXJlLCBhbiBJUHY2LWVuYWJsZWQgbm9kZSB3aWxsIHJlcXVpcmUg dG8gcmV0cmlldmUgY29uZmlndXJhdGlvbiB1c2luZyBESENQdjQtb3Zlci1ESENQdjYgYW5kIG5v dCBkaXJlY3RseSB1c2luZyBESENQdjY/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bUWldIFdlIGFyZSB0YWxraW5nIGFib3V0IElQ djYtZW5hYmxlZCBub2RlIGluIElQdjQvSVB2NiB0cmFuc2l0aW9uIHBlcmlvZCwgd2hlbiBJUHY0 IGFuZCBJUHY2IHNlcnZpY2VzIGFyZSBjb2V4aXN0ZWQuIFVzaW5nIERIQ1B2NC1vdmVyLURIQ1B2 NiBjYW4gZ3VhcmFudGVlIGFsbCBESENQLWJhc2VkIHNlcnZpY2VzIHRvIGJlIGNvbmZpZ3VyZWQg Y29ycmVjdGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij5bTWVkXSBXaGF0IGFyZSB0aG9zZSBzZXJ2aWNlcz8gV2h5IHRob3NlIHNlcnZpY2VzIGNhbm5v dCBiZSBjb25maWd1cmVkIHVzaW5nIERIQ1B2Nj8gQmVmb3JlIGRlc2lnbmluZyBhIHNvbHV0aW9u LCB3ZSBuZWVkIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50cyBhbmQNCiB0aGUgbmVlZHMgZmly c3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNvdXJzZSwgaW4gSVB2NiBvbmx5 IEludGVybmV0IHdoZXJlIHRoZXJlIGlzIG5vIGRlbWFuZCBmb3IgSVB2NCBzZXJ2aWNlcywgd2Ug c2hvdWxkIHVzZSBESENQdjYuIEJ1dCBESENQdjQtb3Zlci1ESENQdjYgY2FuIGFsc28gd29yayBp biB0aGlzIGNhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltNZWRdIOKApiBleGNlcHQgdGhhdCBkaGNwdjQtb3Zlci1kaGNwdjYgaW50cm9kdWNlcyBt b3JlIGNvbXBsZXhpdHkgZm9yIG5vdCBvYnZpb3VzIHJlYXNvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlFpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPGJyPg0KTWVkPGJyPg0K PGJyPg0KJmd0Oy0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7RGUmbmJzcDs6IFFpIFN1biBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpzdW5xaS50aHVAZ21haWwuY29tIj5zdW5xaS50aHVAZ21haWwuY29tPC9h Pl08YnI+DQomZ3Q7RW52b3nDqSZuYnNwOzogbHVuZGkgMTUgYXZyaWwgMjAxMyAwNzo1Njxicj4N CiZndDvDgCZuYnNwOzogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE48YnI+DQomZ3Q7Q2MmbmJz cDs6IFRvbWVrIE1ydWdhbHNraTsgPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3 Z0BpZXRmLm9yZzwvYT47IFNvZnR3aXJlcyAoPGEgaHJlZj0ibWFpbHRvOnNvZnR3aXJlc0BpZXRm Lm9yZyI+c29mdHdpcmVzQGlldGYub3JnPC9hPik8YnI+DQomZ3Q7T2JqZXQmbmJzcDs6IFJlOiBb ZGhjd2ddIEFkb3B0aW9uIGNhbGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2 NjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDtEZWFyIE1lZCw8YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5rcyBm b3IgeW91ciByZXNwb25zZS4gSGVyZSBpcyBteSB1bmRlcnN0YW5kaW5nLjxicj4NCiZndDs8YnI+ DQomZ3Q7SU1ITywgZGVmaW5pbmcgb3B0aW9ucyBpbiBESENQdjYgc2VlbXMgdG8gaW50cm9kdWNl IGxlc3MgY29tcGxleGl0eSBpbjxicj4NCiZndDtwcm90b2NvbC4gSG93ZXZlciwgd2UgZG8gbm90 IGtub3cgZm9yIG5vdyB3aGljaCBvcHRpb25zIGFyZSBuZWVkZWQgaW4gdGhlPGJyPg0KJmd0O2Z1 dHVyZS4gSWYgd2UgaGF2ZSB0byBwb3J0IERIQ1B2NCBvcHRpb25zIGludG8gREhDUHY2LCBob3cg bWFueSB0aW1lczxicj4NCiZndDtzaG91bGQgd2UgZG8gdGhlIHdvcms/IExpa2Ugb25lIG5ldyBv cHRpb24gcGVyIDIgeWVhcnMsIG9yIHJlZGVmaW5pbmcgYWxsPGJyPg0KJmd0O0RIQ1B2NCBvcHRp b25zIGludG8gREhDUHY2IGF0IG9uZSB0aW1lPyBUaGUgcHJvcG9zZWQgc29sdXRpb24gdHJpZXMg dG88YnI+DQomZ3Q7YXZvaWQgcG9sbHV0aW5nIHRoZSBESENQdjYgb3B0aW9uIHNwYWNlLCB3aGlj aCBpcyBuZWNlc3NhcnkgZm9yIHRyYW5zaXRpb248YnI+DQomZ3Q7aW4gREhDUC48YnI+DQomZ3Q7 PGJyPg0KJmd0O0Fub3RoZXIgcG9pbnQgaXMgdGhhdCwgZGVmaW5pbmcgb3B0aW9uKHMpIC8gY29u dGFpbmVyIHdvdWxkIHJlcXVpcmUgdGhlPGJyPg0KJmd0O0RIQ1B2NiBlbmdpbmUgdG8gaGFuZGxl IERIQ1B2NCBvcHRpb25zLCB3aGljaCB3b3VsZCBpbnRyb2R1Y2UgbW9yZTxicj4NCiZndDtjb21w bGV4aXR5IHRvIHRoZSBsb2dpYyBhbmQgaW1wbGVtZW50YXRpb24gb2YgZW5kIHBvaW50cy4gVGhl IHByb3Bvc2VkPGJyPg0KJmd0O3NvbHV0aW9uIGxldmVyYWdlcyB0aGUgREhDUHY0IGVuZ2luZSBm b3IgREhDUHY0IG1lc3NhZ2VzIC8gb3B0aW9ucyBhbmQ8YnI+DQomZ3Q7REhDUHY2IGVuZ2luZSBm b3IgREhDUHY2IG1lc3NhZ2VzIC8gb3B0aW9ucy4gVGhlIGVuZCBwb2ludHMgd291bGQ8YnI+DQom Z3Q7Y29tcGF0aWJsZSB0byBib3RoIERIQ1B2NCBwcm9jZXNzIGFuZCBESENQdjYgcHJvY2Vzcy4g VGhpcyBpcyBtb3JlIHN1aXRhYmxlPGJyPg0KJmd0O2ZvciB0aGUgdHJhbnNpdGlvbi48YnI+DQom Z3Q7PGJyPg0KJmd0O0EgdGhpcmQgY29uc2lkZXJhdGlvbiBpcywgaW4gdGhlIGNhc2Ugb2YgSVB2 NiB0cmFuc2l0aW9uLCB0aGUgREhDUCBjbGllbnQ8YnI+DQomZ3Q7KG9uIHRoZSB0dW5uZWwgZW5k cG9pbnQpIGlzIGJvdW5kIHRvIGJlIG1vZGlmaWVkLiBXZSB0aGluayBpdCBiZXR0ZXIgdG88YnI+ DQomZ3Q7bW9kaWZ5IHRoZSBjbGllbnQgY29tcGxldGVseSBmb3IgdGhlIHRyYW5zaXRpb24gcHVy cG9zZS48YnI+DQomZ3Q7PGJyPg0KJmd0O0xhc3QgYnV0IG5vdCB0aGUgbGVhc3QsIHRoZSBwcm9w b3NlZCBzb2x1dGlvbiBpcyBiYXNlZCBvbiB0aGUgREhDUHY2PGJyPg0KJmd0O2luZnJhc3RydWN0 dXJlLCB3aGljaCBoYXMgYmVlbiBkZXBsb3llZCBpbiBvcGVyYXRvcnMnIG5ldHdvcmtzLjxicj4N CiZndDs8YnI+DQomZ3Q7VGhlIERIQ1B2NCBvdmVyIERIQ1B2NiBtZWNoYW5pc20gaXMgYW4gYXJj aGl0ZWN0dXJhbCBkZXZlbG9wbWVudCBmb3IgREhDUDxicj4NCiZndDtwcm90b2NvbCB0byBtZWV0 IHRoZSByZXF1aXJlbWVudHMgZm9yIGNvbmZpZ3VyaW5nIElQdjQgcGFyYW1ldGVycyBhY3Jvc3M8 YnI+DQomZ3Q7dGhlIElQdjYgbmV0d29yay4gV2UgdGhpbmsgaXQgaXMgaW1wb3J0YW50IGZvciB0 aGUgREhDIFdHIHRvIHdvcmsgb24gaXQuPGJyPg0KJmd0Ozxicj4NCiZndDtCZXN0IFJlZ2FyZHMs PGJyPg0KJmd0O1FpIFN1bjxicj4NCiZndDsoU29ycnkgZm9yIHJlc2VuZGluZywgdHJ5IHRvIHN5 bmNocm9uaXplIHdpdGggc29mdHdpcmUgTUwuLi4pPGJyPg0KJmd0Ozxicj4NCiZndDtPbiAyMDEz LTQtMTIsIGF0IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi PuS4i+WNiDwvc3Bhbj43OjQ3LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCiZn dDsmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyZndDsgRGVhciBhbGwsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAoSSBjYyBzb2Z3dGly ZSBhcyB0aGlzIHdvcmsgaXMgYWxzbyByZWxldmFudCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAuKTxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBkbyBub3Qgc3VwcG9ydCB0aGlzIHdvcmsgYXMg aXQgaW5kdWNlcyBtb3JlIGNvbXBsZXhpdHkgY29tcGFyZWQgdG8ganVzdDxicj4NCiZndDtkZWZp bmluZyBhZGVxdWF0ZSBvcHRpb24gaW4gZGhjcHY2LiBEZWZpbmluZyBvbmUgY29udGFpbmVyIG9y IGZldyBESENQdjY8YnI+DQomZ3Q7b3B0aW9ucyBpcyBtdWNoIG1vcmUgc2ltcGxlciB0aGF0IHRo ZSBwcm9wb3NlZCBhcHByb2FjaC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8 YnI+DQomZ3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsgRGUgOiA8YSBocmVmPSJtYWls dG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyI+ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzwvYT4gW21h aWx0bzo8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyI+ZGhjd2ctYm91bmNl c0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQ8YnI+DQomZ3Q7ZGU8YnI+DQomZ3Q7Jmd0OyZndDsg VG9tZWsgTXJ1Z2Fsc2tpPGJyPg0KJmd0OyZndDsmZ3Q7IEVudm95w6kgOiBtZXJjcmVkaSAzIGF2 cmlsIDIwMTMgMTk6NDE8YnI+DQomZ3Q7Jmd0OyZndDsgw4AgOiA8YSBocmVmPSJtYWlsdG86ZGhj d2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBPYmpldCA6 IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhj cHY2PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBkcmFmdCBpcyBhIHJlc3VsdCBvZiB0aGUg ZGlzY3Vzc2lvbiB3ZSBoYWQgZHVyaW5nIGxhc3QgbWVldGluZyBpbjxicj4NCiZndDsmZ3Q7Jmd0 OyBPcmxhbmRvLiBXZSBoYXZlIHZlcnkgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uIGFib3V0IElQdjQg aG9zdHM8YnI+DQomZ3Q7Jmd0OyZndDsgY29uZmlndXJhdGlvbiBpbiBJUHY2LW9ubHkgbmV0d29y ay4gQWZ0ZXIgd2UgcmVhY2hlZCB3aGF0IGxvb2tlZCBsaWtlIGE8YnI+DQomZ3Q7Jmd0OyZndDsg Y29uc2Vuc3VzIGluIHRoZSBtZWV0aW5nIHJvb20sIGNvdXBsZSBmb2xrcyB2b2x1bnRlZXJlZCB0 byB3cml0ZSBkb3duPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBkcmFmdCB0aGF0IHN1bW1hcml6ZXMg dGhhdCBwZXJjZWl2ZWQgY29uc2Vuc3VzLiBUaGlzIGRyYWZ0IGlzIGE8YnI+DQomZ3Q7Jmd0OyZn dDsgcHJvZHVjdCBvZiB0aGlzIGVmZm9ydC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgQXMgcmVxdWVzdGVkIGJ5IGF1dGhvcnMsIHdlIGFyZSBhbm5vdW5jaW5nIGFkb3Rpb24g Y2FsbCBvbjxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhj cHY2LTAxLiBUaGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvPGJyPg0KJmd0OyZndDsmZ3Q7 IGNvbmZpcm0gd2hldGhlciB0aGVyZSBpcyBXRyBjb25zZW5zdXMgdG8gYWRvcHQgdGhpcyB3b3Jr IGFzIERIQyBXRzxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC4gUGxlYXNlIHN0YXRlIHdoZXRoZXIg b3Igbm90IHlvdSdyZSBpbiBmYXZvciBvZiB0aGUgYWRvcHRpb24gYnk8YnI+DQomZ3Q7Jmd0OyZn dDsgcmVwbHlpbmcgdG8gdGhpcyBtYWlsLiBJZiB5b3UgYXJlIG5vdCBpbiBmYXZvciwgcGxlYXNl IGFsc28gc3RhdGUgeW91cjxicj4NCiZndDsmZ3Q7Jmd0OyBvYmplY3Rpb25zIGluIHlvdXIgcmVz cG9uc2UuIFRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGNvbXBsZXRlIG9uIDIwMTMtPGJyPg0KJmd0 OzA0LTxicj4NCiZndDsmZ3Q7Jmd0OyAxNy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyZndDsgQmVybmllICZhbXA7IFRvbWVrPGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDAzLjA0LjIwMTMgMTk6MjAsIE1hcmNp biBTaW9kZWxza2kgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJbiB0aGUgbmFtZSBvZiBh dXRob3JzIG9mIGRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYgSSBhbTxicj4NCiZn dDthc2tpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3Vt ZW50IGJ5IERIQyBXRy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBUaGUgbGF0ZXN0IHZlcnNpb24gKC0wMSkgaXMgYXZhaWxhYmxlIGhlcmU6PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYtPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyAw MS50eHQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYtMDEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjc2tmLWRoYy1kaGNwdjQt b3Zlci1kaGNwdjYtMDE8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gd2hlcmVieSBJUHY0IGNs aWVudCBvYnRhaW5zIGl0czxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgY29uZmlndXJhdGlvbiBmcm9t IHRoZSBESENQdjQgc2VydmVyIHNlcGFyYXRlZCBmcm9tIHRoZSBjbGllbnQgYnkgSVB2Ni08YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IG9ubHkgbmV0d29yayBoYXZpbmcgREhDUHY2IHNlcnZpY2UuIFRo aXMgbWVjaGFuaXNtIGlzIGZyZXF1ZW50bHk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlZmVycmVk IGFzICZxdW90O0RIQ1B2NC1vdmVyLURIQ1B2NiZxdW90Oy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgREhDUHY0IGNsaWVudCdzIHJlcXVlc3QgaXMgY2Fy cmllZCBpbiB0aGUgbmV3bHkgZGVmaW5lZCBESENQdjY8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG1l c3NhZ2VzL29wdGlvbiB0by9mcm9tIHRoZSBzZXJ2ZXIgYW5kIGNhbiBiZSBzZW50IGVpdGhlciB0 aHJvdWdoIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlbGF5IG9yIGRpcmVjdGx5Ljxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IE1hcmNpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IGRoY3dnIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ci IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ro Y3dnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7Jmd0OyZndDsgZGhjd2cgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGhjd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnPC9hPjxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgZGhjd2cgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaGN3ZzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRoY3dnIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0 PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmciPlNv ZnR3aXJlc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9zcGFuPjxicj4NCjxzcGFuPmRoY3dnIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8 c3Bhbj48YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjwv c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dn PC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_8B04163792C7439F99C5692193ECF101ciscocom_-- From Ted.Lemon@nominum.com Mon Apr 15 06:35:05 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5CD21F93BD; Mon, 15 Apr 2013 06:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn1jQgiwNRwY; Mon, 15 Apr 2013 06:35:05 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7E21F93BB; Mon, 15 Apr 2013 06:35:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwCCLLINiNWt2ZfIg0XcHgd4rDPLRdJ@postini.com; Mon, 15 Apr 2013 06:35:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 862CE1B80E7; Mon, 15 Apr 2013 06:35:04 -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 7D4F2190061; Mon, 15 Apr 2013 06:35:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 06:35:04 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA Date: Mon, 15 Apr 2013 13:35:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6F3DF469DA70C449AF7DE1012ED8CECE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:35:05 -0000 On Apr 15, 2013, at 3:40 AM, wrote: > Except "IPv4 addressing"-related configuration, what additional configura= tion parameters can be provisioned with DHCPv4 and not with DHCPv6?=20 > Why in the future, an IPv6-enabled node will require to retrieve configur= ation using DHCPv4-over-DHCPv6 and not directly using DHCPv6? That's exactly the point, Med. We are attempting to separate out legacy s= olutions that continue to require native IPv4 from those that can survive e= ntirely on IPv6, which we expect in the long run to be the vast majority. = The point is simply to say that if you want to configure your IPv4 stack w= ith DHCP, you should, in general, continue to use DHCPv4. There is general agreement that it's pretty harmless, and also quite effici= ent, to provision MAP-E-based solutions using DHCPv6, as long as all they n= eed from the DHCP server is their MAP prefix/port set configuration. But = we are trying to keep the camel's nose from coming any further under the te= nt by explicitly saying how you do any additional provisioning of the IPv4 = stack, should you need to do so. This document also addresses the problem of doing _stateful_, as opposed to= _stateless_ IPv4 address configuration for dual-stack nodes on an IPv6-onl= y network with IPv4 tunneling to AFTRs. In that case, again, the required= extensions to DHCPv6 would be large, and it's actually pretty convenient t= o just leverage the DHCPv6 infrastructure to carry protocol messages to a D= HCPv4 server, which already knows how to do dynamic IPv4 address allocation= . From mohamed.boucadair@orange.com Mon Apr 15 06:49:35 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBE821F9370; Mon, 15 Apr 2013 06:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoIU+6mNz46L; Mon, 15 Apr 2013 06:49:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43321F9349; Mon, 15 Apr 2013 06:49:34 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9766C3B4108; Mon, 15 Apr 2013 15:49:33 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 679D727C083; Mon, 15 Apr 2013 15:49:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 15 Apr 2013 15:49:33 +0200 From: To: Ted Lemon Date: Mon, 15 Apr 2013 15:49:31 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfEA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:49:35 -0000 Hi Ted, I'm afraid there is no camel at all...and only a mirage in a desert. Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: lundi 15 avril 2013 15:35 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >Objet=A0: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > >On Apr 15, 2013, at 3:40 AM, wrote: >> Except "IPv4 addressing"-related configuration, what additional >configuration parameters can be provisioned with DHCPv4 and not with >DHCPv6? >> Why in the future, an IPv6-enabled node will require to retrieve >configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6? > >That's exactly the point, Med. We are attempting to separate out legacy >solutions that continue to require native IPv4 from those that can survive >entirely on IPv6, which we expect in the long run to be the vast majority. >The point is simply to say that if you want to configure your IPv4 stack >with DHCP, you should, in general, continue to use DHCPv4. > >There is general agreement that it's pretty harmless, and also quite >efficient, to provision MAP-E-based solutions using DHCPv6, as long as all >they need from the DHCP server is their MAP prefix/port set configuration. >But we are trying to keep the camel's nose from coming any further under >the tent by explicitly saying how you do any additional provisioning of th= e >IPv4 stack, should you need to do so. > >This document also addresses the problem of doing _stateful_, as opposed t= o >_stateless_ IPv4 address configuration for dual-stack nodes on an IPv6-onl= y >network with IPv4 tunneling to AFTRs. In that case, again, the required >extensions to DHCPv6 would be large, and it's actually pretty convenient t= o >just leverage the DHCPv6 infrastructure to carry protocol messages to a >DHCPv4 server, which already knows how to do dynamic IPv4 address >allocation. From Ted.Lemon@nominum.com Mon Apr 15 06:53:52 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C36421F86DC; Mon, 15 Apr 2013 06:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 gc7SQZ1SODgE; Mon, 15 Apr 2013 06:53:52 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id D632121F86C5; Mon, 15 Apr 2013 06:53:51 -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 DSNKUWwGb0QnqOfIp9ZuD002LLtpuqL+yaz5@postini.com; Mon, 15 Apr 2013 06:53: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 0A53E1B80E9; Mon, 15 Apr 2013 06:53:51 -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 F3859190061; Mon, 15 Apr 2013 06:53: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.02.0318.004; Mon, 15 Apr 2013 06:53:51 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAFjyAgAAJ94CAAEgwgA== Date: Mon, 15 Apr 2013 13:53:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775148A48@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775148A48mbx01winnominum_" MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:53:52 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775148A48mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 15, 2013, at 5:35 AM, > wrote: some service providers and services may remain in IPv4 for some time, while= end users may demand these IPv4 services to be delivered over IPv6. The re= quired info may be more than IPv4 addresses (port set). As for examples, IM= HO, SIP server option and [Med] This is doable using option 21. The name can be resolved to an IPv6 o= r an IPv4 address. Nothing prevent from doing so. NTP server option are potential customers for this usage. [Med] This is doable using dhcpv6. Why the use dhpv4-over-dhcpv6 is a must? There may be more, because demands are arising with time going on. [Med] I=92m still not seeing any particular demand which cannot be honored = using dhcpv6. Exactly right. DHCPv4-over-DHCPv6 is _not_ a must if you have a working I= Pv6 service infrastructure and are using stateless prefix mapping for IPv4 = transport. Your home gateway can even answer DNS queries it receives on t= he local network over IPv4 by doing the lookups directly to the DNS server = over IPv6=97there is no reason at all why a configuration like this require= s any DHCPv4 configuration options at all, even though it's supporting IPv4= in the home. --_000_8D23D4052ABE7A4490E77B1A012B630775148A48mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <526A73EEC8DC14458B5F86768AEEAC83@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 15, 2013, at 5:35 AM, <mohamed.boucadair@orange.com> wrote:
some service providers and services may remain in IPv4= for some time, while end users may demand these IPv4 services to be delive= red over IPv6. The= required info may be more than IPv4 addresses (port set). As for examples, IMHO, SIP server option and
[Med] This is doable using option 21. The name c= an be resolved to an IPv6 or an IPv4 address. Nothing prevent from doing so= .
 
NTP server option are potential customers for this usa= ge.
[Med] This is doable using dhcpv6. Why the use d= hpv4-over-dhcpv6 is a must?
 
There may be more, because demands are arising with ti= me going on.
[Med] I=92m still not seeing any particular dema= nd which cannot be honored using dhcpv6.

Exactly right.   DHCPv4-over-DHCPv6 is _not_ a must if you have a= working IPv6 service infrastructure and are using stateless prefix mapping= for IPv4 transport.   Your home gateway can even answer DNS queries i= t receives on the local network over IPv4 by doing the lookups directly to the DNS server over IPv6=97there is no re= ason at all why a configuration like this requires any DHCPv4 configuration= options at all, even though it's supporting IPv4 in the home.

--_000_8D23D4052ABE7A4490E77B1A012B630775148A48mbx01winnominum_-- From Ted.Lemon@nominum.com Mon Apr 15 06:55:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322E621F93D0; Mon, 15 Apr 2013 06:55: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=[AWL=-0.000, 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 Eo8c4BFvV0aH; Mon, 15 Apr 2013 06:55:19 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAF021F93C6; Mon, 15 Apr 2013 06:55:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwGx7Ncwhyfgomo/pLGrTxV00Lx0Sv8@postini.com; Mon, 15 Apr 2013 06:55:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2E32A1B80E7; Mon, 15 Apr 2013 06:55:19 -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 273B4190061; Mon, 15 Apr 2013 06:55:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 06:55:19 -0700 From: Ted Lemon To: "Rajiv Asati (rajiva)" Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOcBsXPoVcX6HuU652gzau8YawZjXw5CA Date: Mon, 15 Apr 2013 13:55:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775148A82@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775148A82mbx01winnominum_" MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:55:20 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775148A82mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 15, 2013, at 6:02 AM, "Rajiv Asati (rajiva)" > wrote: And the ones that are really needed, would better move to dhcvpv6 sooner t= han later. It would be prudent for us to do find the delta instead of carry= ing over the legacy and getting the relevant ones fixed. Or has that work b= een done already? Why would _any_ be needed? --_000_8D23D4052ABE7A4490E77B1A012B630775148A82mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 15, 2013, at 6:02 AM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
And the ones that are really needed,  would better move to dhcvpv6 sooner= than later. It would be prudent for us to do find the delta instead of car= rying over the legacy and getting the relevant ones fixed. Or has that work= been done already? 

Why would _any_ be needed?

--_000_8D23D4052ABE7A4490E77B1A012B630775148A82mbx01winnominum_-- From Ted.Lemon@nominum.com Mon Apr 15 06:58:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0080921F8A74 for ; Mon, 15 Apr 2013 06:58:32 -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=[AWL=-0.000, 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 2T0LUjC+YU7S for ; Mon, 15 Apr 2013 06:58:31 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3750421F89DB for ; Mon, 15 Apr 2013 06:58:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwHhy38J4w+a2sovRoeDo3H3fPakFw/@postini.com; Mon, 15 Apr 2013 06:58:31 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 D9A2E1B80E7 for ; Mon, 15 Apr 2013 06:58:30 -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 D3941190061; Mon, 15 Apr 2013 06:58:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 06:58:31 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOHvI3k2MoTLQa0uUqsbeRb1B3pjV79oAgABHQwCAAVUygIAAOq+A Date: Mon, 15 Apr 2013 13:58:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775148ABD@mbx-01.win.nominum.com> References: <77D82DCE-2C81-48B4-B4E9-EA30CCC73449@fugue.com> <516A7C4C.8010207@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775146765@mbx-01.win.nominum.com> <516BD64B.8000606@s-carlsen.dk> In-Reply-To: <516BD64B.8000606@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775148ABDmbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 13:58:32 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775148ABDmbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 15, 2013, at 6:28 AM, Sten Carlsen > wrote: I don't have the information you ask for. OTOH I have seen this particular = question come up in the DHCP-users so often that it looks like a common set= up. Fair enough. I see it come up on dhcp-users too; it usually looks like a p= rototyping scenario when I've seen these questions raised. It also makes = sense in low-demand environments where you're using a native linux machine = as a router. It's probably worth mentioning this in the document; I don't= think it's the most common use case, by far, but it's certainly true that = you can do things this way, and the document shouldn't exclude that possibi= lity. --_000_8D23D4052ABE7A4490E77B1A012B630775148ABDmbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <908C86947837A6489D0DD27268553C71@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 15, 2013, at 6:28 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
I don't have the information you ask for. OTOH I have seen this particular q= uestion come up in the DHCP-users so often that it looks like a common setu= p.

Fair enough.  I see it come up on dhcp-users too; it usually look= s like a prototyping scenario when I've seen these questions raised.  = It also makes sense in low-demand environments where you're using a native= linux machine as a router.   It's probably worth mentioning this in the document; I don't think it's the most common = use case, by far, but it's certainly true that you can do things this way, = and the document shouldn't exclude that possibility.

--_000_8D23D4052ABE7A4490E77B1A012B630775148ABDmbx01winnominum_-- From Ted.Lemon@nominum.com Mon Apr 15 07:09:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD821F93D2; Mon, 15 Apr 2013 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4XWk1+j7Pnl; Mon, 15 Apr 2013 07:09:13 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2701E21F93D0; Mon, 15 Apr 2013 07:09:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwKCCKoBA2Va0qnSkK1ErHq3BJVh9v1@postini.com; Mon, 15 Apr 2013 07:09: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 ABE1E1B80E9; Mon, 15 Apr 2013 07:09:12 -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 A0B5A190061; Mon, 15 Apr 2013 07:09:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 07:09:12 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgA== Date: Mon, 15 Apr 2013 14:09:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4684D77ABA6492469260DCB43CBDD6EF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:09:13 -0000 On Apr 15, 2013, at 9:49 AM, wrote: > I'm afraid there is no camel at all...and only a mirage in a desert. This is not a technical argument. In any case, if there is a mirage, it does no harm, because you aren't requ= ired to use it if you are just doing straightforward MAP-E, right? From mohamed.boucadair@orange.com Mon Apr 15 07:27:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C136921F8615; Mon, 15 Apr 2013 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v1ehOn5mQC4; Mon, 15 Apr 2013 07:27:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5221F860B; Mon, 15 Apr 2013 07:27:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 12DBB3B416B; Mon, 15 Apr 2013 16:27:41 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C108F27C085; Mon, 15 Apr 2013 16:27:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 15 Apr 2013 16:27:40 +0200 From: To: Ted Lemon Date: Mon, 15 Apr 2013 16:27:39 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgP//jt3Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:27:43 -0000 Ted,=20 Are you saying MAP is not a concerned with this draft and dhcpv6 can be use= d for MAP? Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: lundi 15 avril 2013 16:09 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >Objet=A0: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > >On Apr 15, 2013, at 9:49 AM, wrote: >> I'm afraid there is no camel at all...and only a mirage in a desert. > >This is not a technical argument. > >In any case, if there is a mirage, it does no harm, because you aren't >required to use it if you are just doing straightforward MAP-E, right? From Ted.Lemon@nominum.com Mon Apr 15 07:38:55 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0FA21F8E94; Mon, 15 Apr 2013 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVBT5kN7PltN; Mon, 15 Apr 2013 07:38:54 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8137921F905B; Mon, 15 Apr 2013 07:38:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwQ/u+eLqOcRemuwHky/2aRvUQTOQyl@postini.com; Mon, 15 Apr 2013 07:38:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 43E971B80E1; Mon, 15 Apr 2013 07:38:54 -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 3C210190061; Mon, 15 Apr 2013 07:38:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 07:38:54 -0700 From: Ted Lemon To: " " Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgP//jt3QgAB5b4A= Date: Mon, 15 Apr 2013 14:38:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775148D9E@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <43B8A3C1B3A3CE4799031F500F579B52@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:38:55 -0000 On Apr 15, 2013, at 10:27 AM, wrote: > Are you saying MAP is not a concerned with this draft and dhcpv6 can be u= sed for MAP? For configuring the MAP-E prefix and port set, yes. That was the discussi= on we had in Softwires in Orlando: cover the easy stuff with DHCPv6 (this i= s the existing DHCPv6 MAP option), and then if someone needs legacy IPv4 se= rvices or stateful address allocation, do it with DHCPv4-over-DHCPv6. From mohamed.boucadair@orange.com Mon Apr 15 07:47:56 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0F21F89DB; Mon, 15 Apr 2013 07:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnFjRnyQ-cZJ; Mon, 15 Apr 2013 07:47:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16321F8659; Mon, 15 Apr 2013 07:47:56 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 68C0C2DC15B; Mon, 15 Apr 2013 16:47:55 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4C74735C048; Mon, 15 Apr 2013 16:47:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 15 Apr 2013 16:47:55 +0200 From: To: Ted Lemon Date: Mon, 15 Apr 2013 16:47:55 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgP//jt3QgAB5b4D//4tVwA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148D9E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775148D9E@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.15.134520 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:47:57 -0000 Re-, Thanks for clarifying Ted. I must admit this is not what I understood when = I read draft-scskf-*. Does the same conclusion applies also for lw-4over6? (I'm naively assuming,= given the approach defined in draft-ietf-softwire-unified-cpe, the same dh= cpv6 to configure MAP will also be used lw-4over6) Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: lundi 15 avril 2013 16:39 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >Objet=A0: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > >On Apr 15, 2013, at 10:27 AM, wrote: >> Are you saying MAP is not a concerned with this draft and dhcpv6 can be >used for MAP? > >For configuring the MAP-E prefix and port set, yes. That was the >discussion we had in Softwires in Orlando: cover the easy stuff with DHCPv= 6 >(this is the existing DHCPv6 MAP option), and then if someone needs legacy >IPv4 services or stateful address allocation, do it with DHCPv4-over- >DHCPv6. From Ted.Lemon@nominum.com Mon Apr 15 07:51:46 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FAF21F8B27; Mon, 15 Apr 2013 07:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFhbu3cmGFut; Mon, 15 Apr 2013 07:51:45 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA4121F90D9; Mon, 15 Apr 2013 07:51:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwUAcDrqF4Z9kUxw0Wx9vfqkkEmamqe@postini.com; Mon, 15 Apr 2013 07:51:45 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 E01721B80E5; Mon, 15 Apr 2013 07:51:44 -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 D93D7190061; Mon, 15 Apr 2013 07:51:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 07:51:45 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgP//jt3QgAB5b4D//4tVwAAPCDeA Date: Mon, 15 Apr 2013 14:51:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775148E3D@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148D9E@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:51:46 -0000 On Apr 15, 2013, at 10:47 AM, mohamed.boucadair@orange.com wrote: > Does the same conclusion applies also for lw-4over6? (I'm naively assumin= g, given the approach defined in draft-ietf-softwire-unified-cpe, the same = dhcpv6 to configure MAP will also be used lw-4over6) I think if you're using a purely deterministic mapping, you can do lw4over6= with just the DHCPv6 option. For deployments where dynamic allocation is= desired, then you need DHCPv4-over-DHCPv6. From ian.farrer@telekom.de Mon Apr 15 07:55:45 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0521F93DF; Mon, 15 Apr 2013 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 r2nuukSh44Bw; Mon, 15 Apr 2013 07:55:45 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D721F93D7; Mon, 15 Apr 2013 07:55:43 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 15 Apr 2013 16:55:39 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 15 Apr 2013 16:55:38 +0200 From: To: , Date: Mon, 15 Apr 2013 16:55:38 +0200 Thread-Topic: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac456UpaXm149FUSRWyBTyyXxBXHqQ== Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org, dhcwg@ietf.org, sunqi.thu@gmail.com Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:55:45 -0000 Hi Med, It would still work for lw-4o6 and the unified CPE. All of the basic params for configuring lw4o6/MAP1:1 can be provisioned through the OPTION_MAP_BIND that is proposed in the unified CPE draft over DHCPv6. Additional DHCPv4 only options would be done via the DHCPv4oDHCPv6 method for both lw4o6 and MAP-E. We still need to agree on which option will be used for provisioning the address of the lwAFTR/MAP BR, however. There was some discussion on this on the SW ML last week, but no conclusion reached. Cheers, Ian On 15/04/2013 16:47, "mohamed.boucadair@orange.com" wrote: >Re-, > >Thanks for clarifying Ted. I must admit this is not what I understood >when I read draft-scskf-*. > >Does the same conclusion applies also for lw-4over6? (I'm naively >assuming, given the approach defined in draft-ietf-softwire-unified-cpe, >the same dhcpv6 to configure MAP will also be used lw-4over6) > >Cheers, >Med > >>-----Message d'origine----- >>De : Ted Lemon [mailto:Ted.Lemon@nominum.com] >>Envoy=E9 : lundi 15 avril 2013 16:39 >>=C0 : BOUCADAIR Mohamed OLNC/OLN >>Cc : Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >>Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 >> >>On Apr 15, 2013, at 10:27 AM, wrote: >>> Are you saying MAP is not a concerned with this draft and dhcpv6 can be >>used for MAP? >> >>For configuring the MAP-E prefix and port set, yes. That was the >>discussion we had in Softwires in Orlando: cover the easy stuff with >>DHCPv6 >>(this is the existing DHCPv6 MAP option), and then if someone needs >>legacy >>IPv4 services or stateful address allocation, do it with DHCPv4-over- >>DHCPv6. > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange.com Mon Apr 15 08:01:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7421F947C; Mon, 15 Apr 2013 08:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVohfRSVRTsy; Mon, 15 Apr 2013 08:01:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AD13021F93FC; Mon, 15 Apr 2013 08:01:44 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1A88A2DC1AB; Mon, 15 Apr 2013 17:01:44 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A2D1F238079; Mon, 15 Apr 2013 17:01:43 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 15 Apr 2013 17:01:43 +0200 From: To: Ted Lemon Date: Mon, 15 Apr 2013 17:01:42 +0200 Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgP//jt3QgAB5b4D//4tVwAAPCDeAAA6HnyA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C6A1@PUEXCB1B.nanterre.francetelecom.fr> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148D9E@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148E3D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775148E3D@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:01:49 -0000 Re-, As the situation is now much more clearer for the static/deterministic mapp= ing, let us focus on the dynamic allocation case. What would prevent a dhcpv6 server to manipulate IPv4 addresses + port rang= e as IPv4-mapped IPv6 prefixes for instance? Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: lundi 15 avril 2013 16:52 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >Objet=A0: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 > >On Apr 15, 2013, at 10:47 AM, mohamed.boucadair@orange.com wrote: >> Does the same conclusion applies also for lw-4over6? (I'm naively >assuming, given the approach defined in draft-ietf-softwire-unified-cpe, >the same dhcpv6 to configure MAP will also be used lw-4over6) > >I think if you're using a purely deterministic mapping, you can do lw4over= 6 >with just the DHCPv6 option. For deployments where dynamic allocation is >desired, then you need DHCPv4-over-DHCPv6. From sunqi.thu@gmail.com Mon Apr 15 07:16:31 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DD921F949F; Mon, 15 Apr 2013 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGcjzGZ9cLFy; Mon, 15 Apr 2013 07:16:29 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 757A121F9437; Mon, 15 Apr 2013 07:16:28 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kl13so2575470pab.18 for ; Mon, 15 Apr 2013 07:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=G5+WMUaUndQLqpTvIlxF5wju9cXmna3wKV9h8rBVXF8=; b=L55C7RtBW3DvyNWrqrFoGNY88EXeU4ZU0oCuasUkwtBAqm+s84JtsLxVs0nqbnoqID vqfyBld+2LOvyaOPstOwvxx8xxjDfwp6RR2KdiYLKrCz+bAOo5SjUPpDBfvx6oWyGqJi WBUeFIttjoaR9n8dltDLaoqBRQBgk3EaJUbLnrbMwGRxOMAcgoLMlRmBdLaw2/ar10oN T9pIiPAtxOMSAFyeEdTynjoivhwQAWrBbEIPkCrTWxY8ShLhmMip7Ox7bo4vh19wqUX2 4WISoi1rA4lr/WbnJLoE9JYbWwFqIoLh3QsFZ+S8iqCQFffKf5oPNAF+H9fZCAZJs9w6 tXbA== X-Received: by 10.68.190.202 with SMTP id gs10mr29068633pbc.192.1366035388230; Mon, 15 Apr 2013 07:16:28 -0700 (PDT) Received: from [192.168.0.113] ([114.255.40.13]) by mx.google.com with ESMTPS id be10sm20481903pbd.30.2013.04.15.07.16.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 07:16:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7--966365533 From: Qi Sun In-Reply-To: Date: Mon, 15 Apr 2013 22:16:14 +0800 Message-Id: <8C3AB960-81EE-49C0-A7A7-BDF1CDB57FC6@gmail.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC2D7C478@PUEXCB1B.nanterre.francetelecom.fr> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 15 Apr 2013 08:02:16 -0700 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:16:31 -0000 --Apple-Mail-7--966365533 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Rajiv, If all the required information / parameters are moved to DHCPv6 & IPv6, = that means the customers and providers of those services have migrated = to IPv6. However, that is not the situation. Customers and service = providers would remain in IPv4 for some time (transition period). What's = more, it is not quite clear for now which ones are really needed. So = it's hard to decide which options to be / not to be moved to DHCPv6.=20 In this case, original DHCPv4 engine will handle all the DHCPv4-related = parameters. So that I think DHCPv4-over-DHCPv6 is needed. Best Regards, Qi Sun On 2013-4-15, at =E4=B8=8B=E5=8D=886:02, Rajiv Asati (rajiva) wrote: > I agree with Med. In reality, it is highly unlikely that each and = every Dhcpv4 option would be needed for an ipv6 only host. >=20 > And the ones that are really needed, would better move to dhcvpv6 = sooner than later. It would be prudent for us to do find the delta = instead of carrying over the legacy and getting the relevant ones fixed. = Or has that work been done already?=20 >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Apr 15, 2013, at 5:36 AM, "mohamed.boucadair@orange.com" = wrote: >=20 >> Re-, >> =20 >> Please see inline. >> =20 >> Cheers, >> Med >> =20 >> De : Qi Sun [mailto:sunqi.csnet.thu@gmail.com]=20 >> Envoy=C3=A9 : lundi 15 avril 2013 11:00 >> =C3=80 : BOUCADAIR Mohamed OLNC/OLN >> Cc : dhcwg@ietf.org; Softwires (softwires@ietf.org) >> Objet : Re: [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6 >> =20 >> Dear Med, >> =20 >> Please see inline. >> =20 >> Except "IPv4 addressing"-related configuration, what additional = configuration parameters can be provisioned with DHCPv4 and not with = DHCPv6? >> =20 >> [Qi] There are over 200 DHCPv4 options that may be required to = provide IPv4 services. In the period of transition, >> [Med] The question is not how many dhcpv4 exist, but which ones are = really needed when the host is IPv6-enabled. >> =20 >> =20 >> some service providers and services may remain in IPv4 for some time, = while end users may demand these IPv4 services to be delivered over = IPv6. The required info may be more than IPv4 addresses (port set). As = for examples, IMHO, SIP server option and >> [Med] This is doable using option 21. The name can be resolved to an = IPv6 or an IPv4 address. Nothing prevent from doing so. >> =20 >> NTP server option are potential customers for this usage. >> [Med] This is doable using dhcpv6. Why the use dhpv4-over-dhcpv6 is a = must? >> =20 >> There may be more, because demands are arising with time going on. >> [Med] I=E2=80=99m still not seeing any particular demand which cannot = be honored using dhcpv6. >> =20 >> =20 >> Why in the future, an IPv6-enabled node will require to retrieve = configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6? >> =20 >> [Qi] We are talking about IPv6-enabled node in IPv4/IPv6 transition = period, when IPv4 and IPv6 services are coexisted. Using = DHCPv4-over-DHCPv6 can guarantee all DHCP-based services to be = configured correctly. >> =20 >> [Med] What are those services? Why those services cannot be = configured using DHCPv6? Before designing a solution, we need understand = the requirements and the needs first. >> =20 >> Of course, in IPv6 only Internet where there is no demand for IPv4 = services, we should use DHCPv6. But DHCPv4-over-DHCPv6 can also work in = this case. >> =20 >> [Med] =E2=80=A6 except that dhcpv4-over-dhcpv6 introduces more = complexity for not obvious reasons. >> =20 >> Best Regards, >> Qi >> =20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : Qi Sun [mailto:sunqi.thu@gmail.com] >> >Envoy=C3=A9 : lundi 15 avril 2013 07:56 >> >=C3=80 : BOUCADAIR Mohamed OLNC/OLN >> >Cc : Tomek Mrugalski; dhcwg@ietf.org; Softwires (softwires@ietf.org) >> >Objet : Re: [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6 >> > >> > >> >Dear Med, >> > >> >Thanks for your response. Here is my understanding. >> > >> >IMHO, defining options in DHCPv6 seems to introduce less complexity = in >> >protocol. However, we do not know for now which options are needed = in the >> >future. If we have to port DHCPv4 options into DHCPv6, how many = times >> >should we do the work? Like one new option per 2 years, or = redefining all >> >DHCPv4 options into DHCPv6 at one time? The proposed solution tries = to >> >avoid polluting the DHCPv6 option space, which is necessary for = transition >> >in DHCP. >> > >> >Another point is that, defining option(s) / container would require = the >> >DHCPv6 engine to handle DHCPv4 options, which would introduce more >> >complexity to the logic and implementation of end points. The = proposed >> >solution leverages the DHCPv4 engine for DHCPv4 messages / options = and >> >DHCPv6 engine for DHCPv6 messages / options. The end points would >> >compatible to both DHCPv4 process and DHCPv6 process. This is more = suitable >> >for the transition. >> > >> >A third consideration is, in the case of IPv6 transition, the DHCP = client >> >(on the tunnel endpoint) is bound to be modified. We think it better = to >> >modify the client completely for the transition purpose. >> > >> >Last but not the least, the proposed solution is based on the DHCPv6 >> >infrastructure, which has been deployed in operators' networks. >> > >> >The DHCPv4 over DHCPv6 mechanism is an architectural development for = DHCP >> >protocol to meet the requirements for configuring IPv4 parameters = across >> >the IPv6 network. We think it is important for the DHC WG to work on = it. >> > >> >Best Regards, >> >Qi Sun >> >(Sorry for resending, try to synchronize with softwire ML...) >> > >> >On 2013-4-12, at =E4=B8=8B=E5=8D=887:47, = >> > wrote: >> > >> >> Dear all, >> >> >> >> (I cc sofwtire as this work is also relevant for the working = group.) >> >> >> >> I do not support this work as it induces more complexity compared = to just >> >defining adequate option in dhcpv6. Defining one container or few = DHCPv6 >> >options is much more simpler that the proposed approach. >> >> >> >> Cheers, >> >> Med >> >> >> >>> -----Message d'origine----- >> >>> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la = part >> >de >> >>> Tomek Mrugalski >> >>> Envoy=C3=A9 : mercredi 3 avril 2013 19:41 >> >>> =C3=80 : dhcwg@ietf.org >> >>> Objet : [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6 >> >>> >> >>> Hi all, >> >>> >> >>> This draft is a result of the discussion we had during last = meeting in >> >>> Orlando. We have very productive discussion about IPv4 hosts >> >>> configuration in IPv6-only network. After we reached what looked = like a >> >>> consensus in the meeting room, couple folks volunteered to write = down >> >>> the draft that summarizes that perceived consensus. This draft is = a >> >>> product of this effort. >> >>> >> >>> As requested by authors, we are announcing adotion call on >> >>> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being = initiated to >> >>> confirm whether there is WG consensus to adopt this work as DHC = WG >> >>> draft. Please state whether or not you're in favor of the = adoption by >> >>> replying to this mail. If you are not in favor, please also state = your >> >>> objections in your response. This adoption call will complete on = 2013- >> >04- >> >>> 17. >> >>> >> >>> Regards, >> >>> Bernie & Tomek >> >>> >> >>> On 03.04.2013 19:20, Marcin Siodelski wrote: >> >>>> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I = am >> >asking >> >>>> for adoption of this document by DHC WG. >> >>>> >> >>>> The latest version (-01) is available here: >> >>>> >> >>>> = http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6- >> >>> 01.txt >> >>>> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 >> >>>> >> >>>> This document describes a mechanism whereby IPv4 client obtains = its >> >>>> configuration from the DHCPv4 server separated from the client = by IPv6- >> >>>> only network having DHCPv6 service. This mechanism is frequently >> >>>> referred as "DHCPv4-over-DHCPv6". >> >>>> >> >>>> The DHCPv4 client's request is carried in the newly defined = DHCPv6 >> >>>> messages/option to/from the server and can be sent either = through a >> >>>> relay or directly. >> >>>> >> >>>> Cheers, >> >>>> Marcin >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> dhcwg mailing list >> >>>> dhcwg@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/dhcwg >> >>>> >> >>> >> >>> _______________________________________________ >> >>> dhcwg mailing list >> >>> dhcwg@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/dhcwg >> >> _______________________________________________ >> >> dhcwg mailing list >> >> dhcwg@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> =20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-7--966365533 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = Rajiv,

If all the required information / = parameters are moved to DHCPv6 & IPv6, that means the customers and = providers of those services have migrated to IPv6. However, that is not = the situation. Customers and service providers would remain in IPv4 for = some time (transition period). What's more, it is not quite clear for = now which ones are really needed. So it's hard to decide which options = to be / not to be moved to DHCPv6. 

In = this case, original DHCPv4 engine will handle all the DHCPv4-related = parameters. So that I think DHCPv4-over-DHCPv6 is = needed.


Best Regards,
Qi = Sun

On 2013-4-15, at =E4=B8=8B=E5=8D=886:02, Rajiv Asati = (rajiva) wrote:

I agree with Med. In reality, it is highly unlikely that each and = every Dhcpv4 option would be needed for an ipv6 only host.

And the ones that are really needed,  would better move to = dhcvpv6 sooner than later. It would be prudent for us to do find the = delta instead of carrying over the legacy and getting the relevant ones = fixed. Or has that work been done already? 

Cheers,
Rajiv

Sent from my Phone

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Qi Sun [mailto:sunqi.csnet.thu@gmail.com= ]
Envoy=C3=A9 : lundi 15 avril 2013 11:00
=C3=80 : BOUCADAIR Mohamed OLNC/OLN
Cc : dhcwg@ietf.org; = Softwires (softwires@ietf.org)
Objet : Re: [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6

 

Dear Med,

 

Please see inline.

 

Except "IPv4 addressing"-related configuration, what = additional configuration parameters can be provisioned with DHCPv4 and = not with DHCPv6?

 

[Qi] There are over 200 DHCPv4 options that = may be required to provide IPv4 services. In the period of transition,

[Med] The question is not how many dhcpv4 = exist, but which ones are really needed when the host is = IPv6-enabled.

 

 

some service providers and = services may remain in IPv4 for some time, while end users may demand = these IPv4 services to be delivered over IPv6. The required info may be more than IPv4 addresses (port set). As = for examples, IMHO, SIP server option and

[Med] This is doable using option 21. The name = can be resolved to an IPv6 or an IPv4 address. Nothing prevent from = doing so.

 

NTP server option are potential = customers for this usage.

[Med] This is doable using dhcpv6. Why the use = dhpv4-over-dhcpv6 is a must?

 

There may be more, because = demands are arising with time going on.

[Med] I=E2=80=99m still not seeing any = particular demand which cannot be honored using = dhcpv6.

 

 

Why in the future, an IPv6-enabled node will require = to retrieve configuration using DHCPv4-over-DHCPv6 and not directly = using DHCPv6?

 

[Qi] We are talking about IPv6-enabled node = in IPv4/IPv6 transition period, when IPv4 and IPv6 services are = coexisted. Using DHCPv4-over-DHCPv6 can guarantee all DHCP-based = services to be configured correctly.

 

[Med] What are those services? Why those = services cannot be configured using DHCPv6? Before designing a solution, = we need understand the requirements and the needs first.

 

Of course, in IPv6 only Internet where there = is no demand for IPv4 services, we should use DHCPv6. But = DHCPv4-over-DHCPv6 can also work in this case.

 

[Med] =E2=80=A6 except that dhcpv4-over-dhcpv6 = introduces more complexity for not obvious = reasons.

 

Best Regards,

Qi

 

Cheers,
Med

>-----Message d'origine-----

>De : Qi Sun [mailto:sunqi.thu@gmail.com]
>Envoy=C3=A9 : lundi 15 avril 2013 07:56
>=C3=80 : BOUCADAIR Mohamed OLNC/OLN
>Cc : Tomek Mrugalski; dhcwg@ietf.org; Softwires (softwires@ietf.org)
>Objet : Re: [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6

>
>
>Dear Med,
>
>Thanks for your response. Here is my understanding.
>
>IMHO, defining options in DHCPv6 seems to introduce less complexity = in
>protocol. However, we do not know for now which options are needed = in the
>future. If we have to port DHCPv4 options into DHCPv6, how many = times
>should we do the work? Like one new option per 2 years, or = redefining all
>DHCPv4 options into DHCPv6 at one time? The proposed solution tries = to
>avoid polluting the DHCPv6 option space, which is necessary for = transition
>in DHCP.
>
>Another point is that, defining option(s) / container would require = the
>DHCPv6 engine to handle DHCPv4 options, which would introduce = more
>complexity to the logic and implementation of end points. The = proposed
>solution leverages the DHCPv4 engine for DHCPv4 messages / options = and
>DHCPv6 engine for DHCPv6 messages / options. The end points = would
>compatible to both DHCPv4 process and DHCPv6 process. This is more = suitable
>for the transition.
>
>A third consideration is, in the case of IPv6 transition, the DHCP = client
>(on the tunnel endpoint) is bound to be modified. We think it better = to
>modify the client completely for the transition purpose.
>
>Last but not the least, the proposed solution is based on the = DHCPv6
>infrastructure, which has been deployed in operators' networks.
>
>The DHCPv4 over DHCPv6 mechanism is an architectural development for = DHCP
>protocol to meet the requirements for configuring IPv4 parameters = across
>the IPv6 network. We think it is important for the DHC WG to work on = it.
>
>Best Regards,
>Qi Sun
>(Sorry for resending, try to synchronize with softwire ML...)
>
>On 2013-4-12, at =E4=B8=8B=E5=8D=887:47, <mohamed.boucadair@orange.com<= /a>>
><mohamed.boucadair@orange.com<= /a>> wrote:
>
>> Dear all,
>>
>> (I cc sofwtire as this work is also relevant for the working = group.)
>>
>> I do not support this work as it induces more complexity = compared to just
>defining adequate option in dhcpv6. Defining one container or few = DHCPv6
>options is much more simpler that the proposed approach.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] De la = part
>de
>>> Tomek Mrugalski
>>> Envoy=C3=A9 : mercredi 3 avril 2013 19:41
>>> =C3=80 : dhcwg@ietf.org
>>> Objet : [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6
>>>
>>> Hi all,
>>>
>>> This draft is a result of the discussion we had during last = meeting in
>>> Orlando. We have very productive discussion about IPv4 = hosts
>>> configuration in IPv6-only network. After we reached what = looked like a
>>> consensus in the meeting room, couple folks volunteered to = write down
>>> the draft that summarizes that perceived consensus. This = draft is a
>>> product of this effort.
>>>
>>> As requested by authors, we are announcing adotion call = on
>>> draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being = initiated to
>>> confirm whether there is WG consensus to adopt this work as = DHC WG
>>> draft. Please state whether or not you're in favor of the = adoption by
>>> replying to this mail. If you are not in favor, please also = state your
>>> objections in your response. This adoption call will = complete on 2013-
>04-
>>> 17.
>>>
>>> Regards,
>>> Bernie & Tomek
>>>
>>> On 03.04.2013 19:20, Marcin Siodelski wrote:
>>>> In the name of authors of = draft-scskf-dhc-dhcpv4-over-dhcpv6 I am
>asking
>>>> for adoption of this document by DHC WG.
>>>>
>>>> The latest version (-01) is available here:
>>>>
>>>> = http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6-
>>> 01.txt
>>>> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01
>>>>
>>>> This document describes a mechanism whereby IPv4 client = obtains its
>>>> configuration from the DHCPv4 server separated from the = client by IPv6-
>>>> only network having DHCPv6 service. This mechanism is = frequently
>>>> referred as "DHCPv4-over-DHCPv6".
>>>>
>>>> The DHCPv4 client's request is carried in the newly = defined DHCPv6
>>>> messages/option to/from the server and can be sent = either through a
>>>> relay or directly.
>>>>
>>>> Cheers,
>>>> Marcin
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>>
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg

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

 

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

= --Apple-Mail-7--966365533-- From mohamed.boucadair@orange.com Mon Apr 15 08:14:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF32921F9027; Mon, 15 Apr 2013 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixigbBimPcUb; Mon, 15 Apr 2013 08:13:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ECDC921F9339; Mon, 15 Apr 2013 08:13:58 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 452C826413E; Mon, 15 Apr 2013 17:13:58 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2089535C061; Mon, 15 Apr 2013 17:13:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 15 Apr 2013 17:13:57 +0200 From: To: "ian.farrer@telekom.de" , "Ted.Lemon@nominum.com" Date: Mon, 15 Apr 2013 17:13:57 +0200 Thread-Topic: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac456UpaXm149FUSRWyBTyyXxBXHqQAAPU8A Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C6B8@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "sunqi.thu@gmail.com" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:14:00 -0000 Hi Ian, Thanks for the clarification. I understood from your answer: dhcpv6 will be used for both MAP and lw4over= 6 and both don't require draft-scskf-* for IP address + port provisioning. Given currently no additional dhcpv4 only options is required for any of th= e solutions we are discussing in softwire, I do still think it is not justi= fied to take on a solution for a problem which may not exist. draft-scskf-* proposal can be revived when there is a real need to support = dhcpv4-only options. No? Cheers, Med >-----Message d'origine----- >De=A0: ian.farrer@telekom.de [mailto:ian.farrer@telekom.de] >Envoy=E9=A0: lundi 15 avril 2013 16:56 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Ted.Lemon@nominum.com >Cc=A0: softwires@ietf.org; dhcwg@ietf.org; sunqi.thu@gmail.com >Objet=A0: Re: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4- >over-dhcpv6 > >Hi Med, > >It would still work for lw-4o6 and the unified CPE. All of the basic >params for configuring lw4o6/MAP1:1 can be provisioned through the >OPTION_MAP_BIND that is proposed in the unified CPE draft over DHCPv6. >Additional DHCPv4 only options would be done via the DHCPv4oDHCPv6 method >for both lw4o6 and MAP-E. > >We still need to agree on which option will be used for provisioning the >address of the lwAFTR/MAP BR, however. There was some discussion on this >on the SW ML last week, but no conclusion reached. > > >Cheers, >Ian > >On 15/04/2013 16:47, "mohamed.boucadair@orange.com" > wrote: > >>Re-, >> >>Thanks for clarifying Ted. I must admit this is not what I understood >>when I read draft-scskf-*. >> >>Does the same conclusion applies also for lw-4over6? (I'm naively >>assuming, given the approach defined in draft-ietf-softwire-unified-cpe, >>the same dhcpv6 to configure MAP will also be used lw-4over6) >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : Ted Lemon [mailto:Ted.Lemon@nominum.com] >>>Envoy=E9 : lundi 15 avril 2013 16:39 >>>=C0 : BOUCADAIR Mohamed OLNC/OLN >>>Cc : Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >>>Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 >>> >>>On Apr 15, 2013, at 10:27 AM, wrote: >>>> Are you saying MAP is not a concerned with this draft and dhcpv6 can b= e >>>used for MAP? >>> >>>For configuring the MAP-E prefix and port set, yes. That was the >>>discussion we had in Softwires in Orlando: cover the easy stuff with >>>DHCPv6 >>>(this is the existing DHCPv6 MAP option), and then if someone needs >>>legacy >>>IPv4 services or stateful address allocation, do it with DHCPv4-over- >>>DHCPv6. >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires From Ted.Lemon@nominum.com Mon Apr 15 08:16:05 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195CA21F934D; Mon, 15 Apr 2013 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YCIe5sj9Mhv; Mon, 15 Apr 2013 08:16:04 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6615D21F9027; Mon, 15 Apr 2013 08:16:04 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwZtCRnJvNRLMobpxJS/XrtMHfwCAHx@postini.com; Mon, 15 Apr 2013 08:16:04 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 035B21B80E7; Mon, 15 Apr 2013 08:16:04 -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 ED82C190061; Mon, 15 Apr 2013 08:16:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 08:16:04 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjS+0CAgARU0wCAAB0NAIAAYyWA//+MfECAAH0NgP//jt3QgAB5b4D//4tVwAAPCDeAAA6HnyD//5KOAA== Date: Mon, 15 Apr 2013 15:16:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775149013@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C0C5@PUEXCB1B.nanterre.francetelecom.fr> <30C6E4B0-BD31-4FB9-BE94-5FD8B9A1C57E@gmail.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C39B@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751488C7@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C5F3@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148BEF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C645@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148D9E@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630775148E3D@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C6A1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C6A1@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <62C7F51EA1520B43879A208B7BCBC4A9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires \(softwires@ietf.org\)" , "dhcwg@ietf.org" , Qi Sun Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:16:05 -0000 On Apr 15, 2013, at 11:01 AM, mohamed.boucadair@orange.com wrote: > What would prevent a dhcpv6 server to manipulate IPv4 addresses + port ra= nge as IPv4-mapped IPv6 prefixes for instance? This would be sort of easy to do as a hack on the client, I guess. Unless= you mean to have the server stuff this information into the MAP option, of= course. But that would be really weird=97the MAP option isn't stateful. = So essentially you're talking about a new stateful extension to DHCPv6, o= n the lines of RFC3633. That's a really heavyweight solution to this prob= lem. From linux@thehobsons.co.uk Mon Apr 15 08:40:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1721F9409 for ; Mon, 15 Apr 2013 08:40:48 -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 4Tm61MdewnUu for ; Mon, 15 Apr 2013 08:40:47 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 201E821F93DC for ; Mon, 15 Apr 2013 08:40:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 4402329F6C for ; Mon, 15 Apr 2013 16:40:45 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QJx38OpnuOm for ; Mon, 15 Apr 2013 16:40:45 +0100 (BST) Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id BE85329F2C for ; Mon, 15 Apr 2013 16:40:44 +0100 (BST) From: "Simon Hobson" To: dhcwg@ietf.org Date: Mon, 15 Apr 2013 16:40:44 +0100 X-Priority: 3 X-Mailer: MailForge 3.0 Mac OS X Message-ID: <0E7A43A57FCD74996D14FF6F1F13E304F@thehobsons.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 15:40:48 -0000 Ted Lemon wrote: >I just submitted a new document to the tracker that attempts to document existing practice with > respect to how DHCP options are derived and sent to clients in modern DHCP servers. This is a > first draft, and probably needs some new examples. People on this mailing list will, I suspect, find > it difficult to remain awake while reading it because it is such old hat to us, but it's been brought to > my attention recently that not everybody in the IETF is an expert on DHCP server configuration; this > document is an attempt to provide a short, pithy tutorial for IETF document writers who are interested > in understanding how DHCP is used in practice. I'd say a very good document. I'd agree with Sten that it would be good to include a non-router relay agent. As you say, it's not a common arrangement, and that probably reinforces the false belief some people have that the agent must be in the router. Use cases I can see would include situations where the user requires more functionality than that provided by the one embedded in their router - though I have to admit I can't think of one right now ! One that does come up on the ISC DHCP users list relates to situation where the backhaul (links C & E in your diagram) are not broadcast media and not supported by the ISC software - though that's an implementation limitation rather than anything inherent in the protocol. Probably the most common situation is cross-department jurisdiction "issues" between those that manage the routers and those that manage the servers. Apart from this, I think I would have been labelling the Relay Agents as Router + Relay Agent. As it stands, it appears that a relay agent is something different to a router and may be a source of confusion. Would something like this be better ? +---+---+ | relay | | + | | router | | A | +---+---+ One section did catch my eye, Section5,Dynamic Lookup where it says : > However, all modern commercial DHCP servers handle name resolution by > querying the resolver each time a DHCP packet comes in. Some readers may miss the subtlety of this. Last I heard this was not the case for the ISC server (which of course isn't commercial software), but the casual reader may be left expecting this dynamic lookup from all "common" servers. From mohamed.boucadair@orange.com Mon Apr 15 08:52:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B503B21F90B8; Mon, 15 Apr 2013 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jICxYtMFaFYl; Mon, 15 Apr 2013 08:52:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B187421F90AC; Mon, 15 Apr 2013 08:52:39 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id EB7C918C20A; Mon, 15 Apr 2013 17:52:38 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C7C114C06B; Mon, 15 Apr 2013 17:52:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 15 Apr 2013 17:52:38 +0200 From: To: Qi Sun Date: Mon, 15 Apr 2013 17:52:37 +0200 Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: Ac458HEdf8MfW25NS5yKJFejn1oYgwAAG9QQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EC2D7C6B8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "Ted.Lemon@nominum.com" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:52:41 -0000 UmUtLA0KDQpUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbnMuDQoNCkkgc3VnZ2VzdCB0aGUgZG9j dW1lbnQgdG8gYmUgdXBkYXRlZCB0byByZWZsZWN0IHRoZSBjbGFyaWZpY2F0aW9ucyB5b3UgcHJv dmlkZWQgYW5kIGFsc28gdGhlIG9uZXMgcHJvdmlkZWQgYnkgSWFuIGFuZCBUZWQgZm9yIE1BUCBh bmQgTHc0b3ZlcjYgY2FzZXMuIFRoZXNlIGFyZSBpbXBvcnRhbnQgaW5wdXRzLg0KDQpJIHdpdGhk cmF3IG15IG9iamVjdGlvbiB0byBoaXMgZG9jdW1lbnQuDQoNClRoYW5rIHlvdSBhbGwgZm9yIHlv dXIgcGF0aWVudCBleHBsYW5hdGlvbnMuDQoNCkNoZWVycywNCk1lZA0KDQo+LS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+RGXCoDogUWkgU3VuIFttYWlsdG86c3VucWkudGh1QGdtYWlsLmNv bV0NCj5FbnZvecOpwqA6IGx1bmRpIDE1IGF2cmlsIDIwMTMgMTc6NDcNCj7DgMKgOiBCT1VDQURB SVIgTW9oYW1lZCBPTE5DL09MTg0KPkNjwqA6IGlhbi5mYXJyZXJAdGVsZWtvbS5kZTsgVGVkLkxl bW9uQG5vbWludW0uY29tOyBzb2Z0d2lyZXNAaWV0Zi5vcmc7DQo+ZGhjd2dAaWV0Zi5vcmcNCj5P YmpldMKgOiBSZTogW2RoY3dnXSBbU29mdHdpcmVzXSBBZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LXNj c2tmLWRoYy1kaGNwdjQtDQo+b3Zlci1kaGNwdjYNCj4NCj4NCj5EZWFyIE1lZCwNCj4NCj5JbiBN QVAtRSBwdXJlIHN0YXRlbGVzcyBtb2RlLCBJUHY0IGFkZHJlc3MgKHByZWZpeCkgYW5kIHBvcnQg c2V0IGFyZQ0KPnByb3Zpc2lvbmVkIGluIE1BUCBSdWxlcyBhcyBkZXNpZ25lZC4gQnV0IGluIE1B UC1FIDE6MSBtb2RlIGFuZCBsdzRvdmVyNg0KPndoaWNoIGFyZSAoa2luZCBvZikgc3RhdGVmdWws IGl0IGhhcyB0byB0YWtlIGludG8gY29uc2lkZXJhdGlvbnMgYWJvdXQgdGhlDQo+bGVhc2UgdGlt ZSBldGMuIGlzc3Vlcy4gSW4gdGhpcyBjYXNlLCBJTUhPLCBESENQdjQgb3ZlciBESENQdjYgaXMg bW9yZQ0KPnN1aXRhYmxlIGZvciBJUHY0IHJlbGF0ZWQgY29uZmlndXJhdGlvbnMuDQo+DQo+V2hh dCdzIG1vcmUsIERIQ1B2NC1vdmVyLURIQ1B2NiBpcyBub3Qgb25seSBkZXNpZ25lZCB0byBkZWFs IHdpdGggdGhlDQo+b3B0aW9uIGlzc3VlcywgYnV0IGFsc28gdG8gaGFuZGxlIG90aGVyIGFyY2hp dGVjdHVyYWwgcHJvYmxlbXMgaW4NCj50cmFuc2l0aW9uIChhcyBCZXJuaWUgbWVudGlvbmVkIGlu IHByZXZpb3VzIG1haWwpLiBTbyBJIHRoaW5rIERIQ1B2NC1vdmVyLQ0KPkRIQ1B2NiBpcyBoZWxw ZnVsIGZvciB0aGUgZXZvbHZlbWVudCBpbiBESENQIGFyY2hpdGVjdHVyZS4NCj4NCj4NCj5CZXN0 IFJlZ2FyZHMsDQo+UWkgU3VuDQo+DQo+DQo+T24gMjAxMy00LTE1LCBhdCDkuIvljYgxMToxMywg PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+IHdyb3RlOg0KPg0KPj4gSGkgSWFuLA0KPj4NCj4+IFRoYW5rcyBmb3IgdGhlIGNsYXJp ZmljYXRpb24uDQo+PiBJIHVuZGVyc3Rvb2QgZnJvbSB5b3VyIGFuc3dlcjogZGhjcHY2IHdpbGwg YmUgdXNlZCBmb3IgYm90aCBNQVAgYW5kDQo+bHc0b3ZlcjYgYW5kIGJvdGggZG9uJ3QgcmVxdWly ZSBkcmFmdC1zY3NrZi0qIGZvciBJUCBhZGRyZXNzICsgcG9ydA0KPnByb3Zpc2lvbmluZy4NCj4+ DQo+PiBHaXZlbiBjdXJyZW50bHkgbm8gYWRkaXRpb25hbCBkaGNwdjQgb25seSBvcHRpb25zIGlz IHJlcXVpcmVkIGZvciBhbnkgb2YNCj50aGUgc29sdXRpb25zIHdlIGFyZSBkaXNjdXNzaW5nIGlu IHNvZnR3aXJlLCBJIGRvIHN0aWxsIHRoaW5rIGl0IGlzIG5vdA0KPmp1c3RpZmllZCB0byB0YWtl IG9uIGEgc29sdXRpb24gZm9yIGEgcHJvYmxlbSB3aGljaCBtYXkgbm90IGV4aXN0Lg0KPj4NCj4+ IGRyYWZ0LXNjc2tmLSogcHJvcG9zYWwgY2FuIGJlIHJldml2ZWQgd2hlbiB0aGVyZSBpcyBhIHJl YWwgbmVlZCB0bw0KPnN1cHBvcnQgZGhjcHY0LW9ubHkgb3B0aW9ucy4gTm8/DQo+Pg0KPj4gQ2hl ZXJzLA0KPj4gTWVkDQo+Pg0KPj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+IERl IDogaWFuLmZhcnJlckB0ZWxla29tLmRlIFttYWlsdG86aWFuLmZhcnJlckB0ZWxla29tLmRlXQ0K Pj4+IEVudm95w6kgOiBsdW5kaSAxNSBhdnJpbCAyMDEzIDE2OjU2DQo+Pj4gw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBPTE5DL09MTjsgVGVkLkxlbW9uQG5vbWludW0uY29tDQo+Pj4gQ2MgOiBzb2Z0 d2lyZXNAaWV0Zi5vcmc7IGRoY3dnQGlldGYub3JnOyBzdW5xaS50aHVAZ21haWwuY29tDQo+Pj4g T2JqZXQgOiBSZTogW1NvZnR3aXJlc10gW2RoY3dnXSBBZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LXNj c2tmLWRoYy1kaGNwdjQtDQo+Pj4gb3Zlci1kaGNwdjYNCj4+Pg0KPj4+IEhpIE1lZCwNCj4+Pg0K Pj4+IEl0IHdvdWxkIHN0aWxsIHdvcmsgZm9yIGx3LTRvNiBhbmQgdGhlIHVuaWZpZWQgQ1BFLiBB bGwgb2YgdGhlIGJhc2ljDQo+Pj4gcGFyYW1zIGZvciBjb25maWd1cmluZyBsdzRvNi9NQVAxOjEg Y2FuIGJlIHByb3Zpc2lvbmVkIHRocm91Z2ggdGhlDQo+Pj4gT1BUSU9OX01BUF9CSU5EIHRoYXQg aXMgcHJvcG9zZWQgaW4gdGhlIHVuaWZpZWQgQ1BFIGRyYWZ0IG92ZXIgREhDUHY2Lg0KPj4+IEFk ZGl0aW9uYWwgREhDUHY0IG9ubHkgb3B0aW9ucyB3b3VsZCBiZSBkb25lIHZpYSB0aGUgREhDUHY0 b0RIQ1B2Ng0KPm1ldGhvZA0KPj4+IGZvciBib3RoIGx3NG82IGFuZCBNQVAtRS4NCj4+Pg0KPj4+ IFdlIHN0aWxsIG5lZWQgdG8gYWdyZWUgb24gd2hpY2ggb3B0aW9uIHdpbGwgYmUgdXNlZCBmb3Ig cHJvdmlzaW9uaW5nIHRoZQ0KPj4+IGFkZHJlc3Mgb2YgdGhlIGx3QUZUUi9NQVAgQlIsIGhvd2V2 ZXIuIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gdGhpcw0KPj4+IG9uIHRoZSBTVyBNTCBs YXN0IHdlZWssIGJ1dCBubyBjb25jbHVzaW9uIHJlYWNoZWQuDQo+Pj4NCj4+Pg0KPj4+IENoZWVy cywNCj4+PiBJYW4NCj4+Pg0KPj4+IE9uIDE1LzA0LzIwMTMgMTY6NDcsICJtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIg0KPj4+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90 ZToNCj4+Pg0KPj4+PiBSZS0sDQo+Pj4+DQo+Pj4+IFRoYW5rcyBmb3IgY2xhcmlmeWluZyBUZWQu IEkgbXVzdCBhZG1pdCB0aGlzIGlzIG5vdCB3aGF0IEkgdW5kZXJzdG9vZA0KPj4+PiB3aGVuIEkg cmVhZCBkcmFmdC1zY3NrZi0qLg0KPj4+Pg0KPj4+PiBEb2VzIHRoZSBzYW1lIGNvbmNsdXNpb24g YXBwbGllcyBhbHNvIGZvciBsdy00b3ZlcjY/IChJJ20gbmFpdmVseQ0KPj4+PiBhc3N1bWluZywg Z2l2ZW4gdGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS11bmlmaWVk LQ0KPmNwZSwNCj4+Pj4gdGhlIHNhbWUgZGhjcHY2IHRvIGNvbmZpZ3VyZSBNQVAgd2lsbCBhbHNv IGJlIHVzZWQgbHctNG92ZXI2KQ0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IE1lZA0KPj4+Pg0K Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+PiBEZSA6IFRlZCBMZW1vbiBb bWFpbHRvOlRlZC5MZW1vbkBub21pbnVtLmNvbV0NCj4+Pj4+IEVudm95w6kgOiBsdW5kaSAxNSBh dnJpbCAyMDEzIDE2OjM5DQo+Pj4+PiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+ Pj4+PiBDYyA6IFFpIFN1bjsgZGhjd2dAaWV0Zi5vcmc7IFNvZnR3aXJlcyAoc29mdHdpcmVzQGll dGYub3JnKQ0KPj4+Pj4gT2JqZXQgOiBSZTogW2RoY3dnXSBBZG9wdGlvbiBjYWxsIG9uIGRyYWZ0 LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci0NCj5kaGNwdjYNCj4+Pj4+DQo+Pj4+PiBPbiBBcHIgMTUs IDIwMTMsIGF0IDEwOjI3IEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6 DQo+Pj4+Pj4gQXJlIHlvdSBzYXlpbmcgTUFQIGlzIG5vdCBhIGNvbmNlcm5lZCB3aXRoIHRoaXMg ZHJhZnQgYW5kIGRoY3B2NiBjYW4NCj5iZQ0KPj4+Pj4gdXNlZCBmb3IgTUFQPw0KPj4+Pj4NCj4+ Pj4+IEZvciBjb25maWd1cmluZyB0aGUgTUFQLUUgcHJlZml4IGFuZCBwb3J0IHNldCwgeWVzLiAg IFRoYXQgd2FzIHRoZQ0KPj4+Pj4gZGlzY3Vzc2lvbiB3ZSBoYWQgaW4gU29mdHdpcmVzIGluIE9y bGFuZG86IGNvdmVyIHRoZSBlYXN5IHN0dWZmIHdpdGgNCj4+Pj4+IERIQ1B2Ng0KPj4+Pj4gKHRo aXMgaXMgdGhlIGV4aXN0aW5nIERIQ1B2NiBNQVAgb3B0aW9uKSwgYW5kIHRoZW4gaWYgc29tZW9u ZSBuZWVkcw0KPj4+Pj4gbGVnYWN5DQo+Pj4+PiBJUHY0IHNlcnZpY2VzIG9yIHN0YXRlZnVsIGFk ZHJlc3MgYWxsb2NhdGlvbiwgZG8gaXQgd2l0aCBESENQdjQtb3Zlci0NCj4+Pj4+IERIQ1B2Ni4N Cj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPj4+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcN Cj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g ZGhjd2cgbWFpbGluZyBsaXN0DQo+PiBkaGN3Z0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQo= From Ted.Lemon@nominum.com Mon Apr 15 09:01:37 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5C121F95B4 for ; Mon, 15 Apr 2013 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxxubhQvp-69 for ; Mon, 15 Apr 2013 09:01:33 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 1B74F21F8F0E for ; Mon, 15 Apr 2013 09:01:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwkOO8R3bzsW47Rh3bOWEdLHM7wDMnI@postini.com; Mon, 15 Apr 2013 09:01:01 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 2D86D1B80EA for ; Mon, 15 Apr 2013 09:00: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 2510A190061; Mon, 15 Apr 2013 09:00: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.02.0318.004; Mon, 15 Apr 2013 09:00:56 -0700 From: Ted Lemon To: Simon Hobson Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOe+X3k2MoTLQa0uUqsbeRb1B3pjX5kuA Date: Mon, 15 Apr 2013 16:00:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514939D@mbx-01.win.nominum.com> References: <0E7A43A57FCD74996D14FF6F1F13E304F@thehobsons.co.uk> In-Reply-To: <0E7A43A57FCD74996D14FF6F1F13E304F@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E619896A696F04894F547133C051162@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 16:01:37 -0000 On Apr 15, 2013, at 11:40 AM, Simon Hobson wrote: > Apart from this, I think I would have been labelling the Relay Agents as = Router + Relay Agent. As it stands, it appears that a relay agent is someth= ing different to a router and may be a source of confusion. Would something= like this be better ? One of the examples I considered using was an LDRA, which is a switch, not = a router. Also, the diagram was getting crowded. So that's why I didn't= draw it that way. But I've adjusted the text in the first to make it cle= ar that the relay is also a router; the other example already mentioned tha= t. I envisioned adding a few more examples, including the LDRA example, b= ut wanted to publish a -00 so that people could take a look at it and comme= nt before adding more text. From volz@cisco.com Mon Apr 15 09:42:02 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14D821F960C for ; Mon, 15 Apr 2013 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua8K4YDmKeVN for ; Mon, 15 Apr 2013 09:42:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7F121F960B for ; Mon, 15 Apr 2013 09:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2118; q=dns/txt; s=iport; t=1366044121; x=1367253721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H3NQ46hztCe7f8rcYtjis5r3JoJTw1y0HpeNjcVT5Jk=; b=ALaRFFihQRiExfBNMyc8G0rJYra/ouESMqaDkyTyIeNqh1Y0l3pEYWPp PWlhmD7Qy2E73UdrtjN+V++faFk78x/Pdz6QwpMI/+DYH/sIMmdjKbxrG OlJMy2I9sV49XXuCsYFaymyjlD8D1eTJRDQsufrfKJ8GrxOVmbpeqsjfa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFADYtbFGtJV2Y/2dsb2JhbABQgwY2wQSBBxZ0gh8BAQEEAQEBGh0xAwsMBAIBCBEEAQEBChQJBycLFAkIAgQOBQiIDAy7bASNVIESJgsHBoJaYQOoFoMLgig X-IronPort-AV: E=Sophos;i="4.87,476,1363132800"; d="scan'208";a="195964529" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 15 Apr 2013 16:42:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3FGg0Qo004130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 16:42:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 11:42:00 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOe+X3k2MoTLQa0uUqsbeRb1B3pjX5kuA//+Tl9A= Date: Mon, 15 Apr 2013 16:41:59 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18506706@xmb-rcd-x04.cisco.com> References: <0E7A43A57FCD74996D14FF6F1F13E304F@thehobsons.co.uk> <8D23D4052ABE7A4490E77B1A012B63077514939D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514939D@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 16:42:02 -0000 (Co-chair hat mostly off.) While fairly "basic" DHCP, it is good work as there are a lot of people out= there that are not DHCP experts. So having something like this to provide = them is great. Two other concepts that are often difficult for non-DHCP experts that shoul= d be considered are: - Shared subnets - this is where multiple subnets are in use on one wire fo= r leasing - Grouped subnets - this is where the giaddr or link-address are on a subne= t/prefix that is not being used for address assignment and thus needs to be= associated with another subnet/prefix. This is similar to the shared subne= t, but no leases are being assigned from one of the subnets (the "source" s= ubnet). Of course, both v4 and v6 examples would be best. (Co-chair hat on.) Do you want a call for adoption of this work? I think it would be a good it= em for the WG to adopt. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, April 15, 2013 12:01 PM To: Simon Hobson Cc: Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf On Apr 15, 2013, at 11:40 AM, Simon Hobson wrote: > Apart from this, I think I would have been labelling the Relay Agents as = Router + Relay Agent. As it stands, it appears that a relay agent is someth= ing different to a router and may be a source of confusion. Would something= like this be better ? One of the examples I considered using was an LDRA, which is a switch, not = a router. Also, the diagram was getting crowded. So that's why I didn't= draw it that way. But I've adjusted the text in the first to make it cle= ar that the relay is also a router; the other example already mentioned tha= t. I envisioned adding a few more examples, including the LDRA example, b= ut wanted to publish a -00 so that people could take a look at it and comme= nt before adding more text. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Apr 15 09:49:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009421F95EF for ; Mon, 15 Apr 2013 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYcQalXLbN+n for ; Mon, 15 Apr 2013 09:49:49 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9021F95E4 for ; Mon, 15 Apr 2013 09:49:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUWwvrA8UfrBLO2ds+e8aTfQKsa6prCBp@postini.com; Mon, 15 Apr 2013 09:49:49 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 93C771B80F0 for ; Mon, 15 Apr 2013 09:49:48 -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 89580190061; Mon, 15 Apr 2013 09:49:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 09:49:48 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOe+X3k2MoTLQa0uUqsbeRb1B3pjX5kuA//+Tl9CAAHoRgA== Date: Mon, 15 Apr 2013 16:49:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775149715@mbx-01.win.nominum.com> References: <0E7A43A57FCD74996D14FF6F1F13E304F@thehobsons.co.uk> <8D23D4052ABE7A4490E77B1A012B63077514939D@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E18506706@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18506706@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 16:49:49 -0000 On Apr 15, 2013, at 12:41 PM, Bernie Volz (volz) wrote: > Two other concepts that are often difficult for non-DHCP experts that sho= uld be considered are: > - Shared subnets - this is where multiple subnets are in use on one wire = for leasing Yup. > - Grouped subnets - this is where the giaddr or link-address are on a sub= net/prefix that is not being used for address assignment and thus needs to = be associated with another subnet/prefix. This is similar to the shared sub= net, but no leases are being assigned from one of the subnets (the "source"= subnet). Are there a lot of cases where this happens? I know there's a lot of goo = in the protocol to support this behavior, but I haven't actually seen it us= ed in the wild. > Do you want a call for adoption of this work? I think it would be a good = item for the WG to adopt. Yes, I was thinking a call for adoption would be a good idea. I could als= o use a co-author. From sunqi.thu@gmail.com Mon Apr 15 08:46:47 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2921F9409; Mon, 15 Apr 2013 08:46: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 o6hildsjj-6Z; Mon, 15 Apr 2013 08:46:46 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7D15321F9404; Mon, 15 Apr 2013 08:46:46 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id jh10so2616184pab.10 for ; Mon, 15 Apr 2013 08:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=KrnWgD2nA4Qa5V2t0m8ThokuOgOXGfJwLnNVxxQnzdU=; b=KVTQSKtfx2xBUDyWoRD0dYbY12d+QDJYfea5dx2fp53BjkPUgzyTYnhCzeDAq+8H+L yB3vGv+Mjf9tUVMJhuwSmxsr70JTiVwUevpadYI2VMM6zUUUfnmI+psR/m4Zw5RtHEQ0 Zgr3GsA5OIM2aaIszqkyx2qdAZaBnqLKQkD+1Wyr8V24wadB+yts1zaJCIbybLmkW6mW gFlfDAN6AASF9SUTY5okbT0aP9xgOu0gqi4UWXNvH62kGeKukJE75CCbbnbGtQm5Y6Bg EPqj+yQDhRGUTAQ3Tgp600jXXAW79D0sLTxUnTWMy2b93EzYRCAWE2TZR/Y/R3SuCRzw DUcg== X-Received: by 10.68.233.135 with SMTP id tw7mr29692948pbc.130.1366040806219; Mon, 15 Apr 2013 08:46:46 -0700 (PDT) Received: from [172.20.10.3] ([219.141.159.62]) by mx.google.com with ESMTPS id ce16sm22520657pac.5.2013.04.15.08.46.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:46:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C6B8@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 15 Apr 2013 23:46:31 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36EC2D7C673@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EC2D7C6B8@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 15 Apr 2013 11:08:16 -0700 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "Ted.Lemon@nominum.com" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:46:47 -0000 Dear Med, In MAP-E pure stateless mode, IPv4 address (prefix) and port set are = provisioned in MAP Rules as designed. But in MAP-E 1:1 mode and lw4over6 = which are (kind of) stateful, it has to take into considerations about = the lease time etc. issues. In this case, IMHO, DHCPv4 over DHCPv6 is = more suitable for IPv4 related configurations.=20 What's more, DHCPv4-over-DHCPv6 is not only designed to deal with the = option issues, but also to handle other architectural problems in = transition (as Bernie mentioned in previous mail). So I think = DHCPv4-over-DHCPv6 is helpful for the evolvement in DHCP architecture.=20= Best Regards, Qi Sun On 2013-4-15, at =E4=B8=8B=E5=8D=8811:13, = wrote: > Hi Ian, >=20 > Thanks for the clarification. > I understood from your answer: dhcpv6 will be used for both MAP and = lw4over6 and both don't require draft-scskf-* for IP address + port = provisioning. >=20 > Given currently no additional dhcpv4 only options is required for any = of the solutions we are discussing in softwire, I do still think it is = not justified to take on a solution for a problem which may not exist. >=20 > draft-scskf-* proposal can be revived when there is a real need to = support dhcpv4-only options. No? >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : ian.farrer@telekom.de [mailto:ian.farrer@telekom.de] >> Envoy=C3=A9 : lundi 15 avril 2013 16:56 >> =C3=80 : BOUCADAIR Mohamed OLNC/OLN; Ted.Lemon@nominum.com >> Cc : softwires@ietf.org; dhcwg@ietf.org; sunqi.thu@gmail.com >> Objet : Re: [Softwires] [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4- >> over-dhcpv6 >>=20 >> Hi Med, >>=20 >> It would still work for lw-4o6 and the unified CPE. All of the basic >> params for configuring lw4o6/MAP1:1 can be provisioned through the >> OPTION_MAP_BIND that is proposed in the unified CPE draft over = DHCPv6. >> Additional DHCPv4 only options would be done via the DHCPv4oDHCPv6 = method >> for both lw4o6 and MAP-E. >>=20 >> We still need to agree on which option will be used for provisioning = the >> address of the lwAFTR/MAP BR, however. There was some discussion on = this >> on the SW ML last week, but no conclusion reached. >>=20 >>=20 >> Cheers, >> Ian >>=20 >> On 15/04/2013 16:47, "mohamed.boucadair@orange.com" >> wrote: >>=20 >>> Re-, >>>=20 >>> Thanks for clarifying Ted. I must admit this is not what I = understood >>> when I read draft-scskf-*. >>>=20 >>> Does the same conclusion applies also for lw-4over6? (I'm naively >>> assuming, given the approach defined in = draft-ietf-softwire-unified-cpe, >>> the same dhcpv6 to configure MAP will also be used lw-4over6) >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Ted Lemon [mailto:Ted.Lemon@nominum.com] >>>> Envoy=C3=A9 : lundi 15 avril 2013 16:39 >>>> =C3=80 : BOUCADAIR Mohamed OLNC/OLN >>>> Cc : Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >>>> Objet : Re: [dhcwg] Adoption call on = draft-scskf-dhc-dhcpv4-over-dhcpv6 >>>>=20 >>>> On Apr 15, 2013, at 10:27 AM, wrote: >>>>> Are you saying MAP is not a concerned with this draft and dhcpv6 = can be >>>> used for MAP? >>>>=20 >>>> For configuring the MAP-E prefix and port set, yes. That was the >>>> discussion we had in Softwires in Orlando: cover the easy stuff = with >>>> DHCPv6 >>>> (this is the existing DHCPv6 MAP option), and then if someone needs >>>> legacy >>>> IPv4 services or stateful address allocation, do it with = DHCPv4-over- >>>> DHCPv6. >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 15 11:48:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56C121F95E4 for ; Mon, 15 Apr 2013 11:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7Tl9nJVytv5 for ; Mon, 15 Apr 2013 11:48:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F00EB21F8F1C for ; Mon, 15 Apr 2013 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=908; q=dns/txt; s=iport; t=1366051686; x=1367261286; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K/MFtFYWCGWuW6yCSSWRjELX9pd2XgH62ub+LDBYySU=; b=dlm/MxduA7jCP34jRv9Rde6oFVME0Ur9Vvnr8D6seSgy6Cg2XOWkXdfz 4MEZcXCtzxB273Bc2zmAfOz3bME7vZ2tAz/EyGWGWr8QuD7/lQ0Y1PDh7 DKZtiO+XHLUcY61/QQb75z4r8aaHcdE58nOOflqEx0OkQRL2ZCSB/ZxD6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMFAK9KbFGtJV2Y/2dsb2JhbABQgwY2gmm+G4EHFnSCHwEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBA4FCAGICwy7YY5mMQcGglphA6gWgwuCKA X-IronPort-AV: E=Sophos;i="4.87,477,1363132800"; d="scan'208";a="199008144" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 15 Apr 2013 18:48:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3FIm5ei002521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 18:48:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 13:48:05 -0500 From: "Bernie Volz (volz)" To: dhcwg Thread-Topic: [dhcwg] IETF86 DHC minutes available Thread-Index: AQHOK+X2x6CoElwsMEmTq0SOiQtlU5jXuxKA Date: Mon, 15 Apr 2013 18:48:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18506BDB@xmb-rcd-x04.cisco.com> References: <5154924E.3080403@gmail.com> In-Reply-To: <5154924E.3080403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] IETF86 DHC minutes available 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 Apr 2013 18:48:06 -0000 I have uploaded the final minutes (the earlier posted by Tomek, minus "DRAF= T"). We received no comments. Thus, the final minutes are now available at http://www.ietf.org/proceeding= s/86/minutes/minutes-86-dhc. Thanks much to Tomek for doing most of the work to pull these together! - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Thursday, March 28, 2013 2:56 PM To: dhcwg Subject: [dhcwg] IETF86 DHC minutes available Hi all, THe draft minutes from Orlando DHC meeting are now available at http://www.ietf.org/proceedings/86/minutes/minutes-86-dhc Please review these minutes and send us changes/additions by April 14th, 20= 13. Regards, Tomek & Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From yiu_lee@cable.comcast.com Mon Apr 15 12:27:14 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E798A21F944A; Mon, 15 Apr 2013 12:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, 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 bVgahoFt8d+x; Mon, 15 Apr 2013 12:27:14 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id DD68321F87F5; Mon, 15 Apr 2013 12:27:13 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.49368148; Mon, 15 Apr 2013 15:24:38 -0400 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 15 Apr 2013 15:27:09 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.236]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Mon, 15 Apr 2013 15:27:09 -0400 From: "Lee, Yiu" To: "mohamed.boucadair@orange.com" , Qi Sun Thread-Topic: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOg845rab7UHe6kuJY9MQXq4y6g== Date: Mon, 15 Apr 2013 19:27:09 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3448884428_1703902" MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:27:15 -0000 --B_3448884428_1703902 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Med, I agree we can talk more motivations in the draft. However, draft-scskf-dhc-dhcpv4-over-dhcpv6 discusses a generic specification of DHCPv4 over DHCPv6. I am not sure what we want to mention specific to MAP or lw4over6 in this draft. Thanks, Yiu On 4/15/13 11:52 AM, "mohamed.boucadair@orange.com" wrote: >Re-, > >Thanks for the explanations. > >I suggest the document to be updated to reflect the clarifications you >provided and also the ones provided by Ian and Ted for MAP and Lw4over6 >cases. These are important inputs. > >I withdraw my objection to his document. > >Thank you all for your patient explanations. > >Cheers, >Med > >>-----Message d'origine----- >>De : Qi Sun [mailto:sunqi.thu@gmail.com] >>Envoy=C3=A9 : lundi 15 avril 2013 17:47 >>=C3=80 : BOUCADAIR Mohamed OLNC/OLN >>Cc : ian.farrer@telekom.de; Ted.Lemon@nominum.com; softwires@ietf.org; >>dhcwg@ietf.org >>Objet : Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4- >>over-dhcpv6 >> >> >>Dear Med, >> >>In MAP-E pure stateless mode, IPv4 address (prefix) and port set are >>provisioned in MAP Rules as designed. But in MAP-E 1:1 mode and lw4over6 >>which are (kind of) stateful, it has to take into considerations about >>the >>lease time etc. issues. In this case, IMHO, DHCPv4 over DHCPv6 is more >>suitable for IPv4 related configurations. >> >>What's more, DHCPv4-over-DHCPv6 is not only designed to deal with the >>option issues, but also to handle other architectural problems in >>transition (as Bernie mentioned in previous mail). So I think >>DHCPv4-over- >>DHCPv6 is helpful for the evolvement in DHCP architecture. >> >> >>Best Regards, >>Qi Sun >> >> >>On 2013-4-15, at =E4=B8=8B=E5=8D=8811:13, >> wrote: >> >>> Hi Ian, >>> >>> Thanks for the clarification. >>> I understood from your answer: dhcpv6 will be used for both MAP and >>lw4over6 and both don't require draft-scskf-* for IP address + port >>provisioning. >>> >>> Given currently no additional dhcpv4 only options is required for any >>>of >>the solutions we are discussing in softwire, I do still think it is not >>justified to take on a solution for a problem which may not exist. >>> >>> draft-scskf-* proposal can be revived when there is a real need to >>support dhcpv4-only options. No? >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : ian.farrer@telekom.de [mailto:ian.farrer@telekom.de] >>>> Envoy=C3=A9 : lundi 15 avril 2013 16:56 >>>> =C3=80 : BOUCADAIR Mohamed OLNC/OLN; Ted.Lemon@nominum.com >>>> Cc : softwires@ietf.org; dhcwg@ietf.org; sunqi.thu@gmail.com >>>> Objet : Re: [Softwires] [dhcwg] Adoption call on >>>>draft-scskf-dhc-dhcpv4- >>>> over-dhcpv6 >>>> >>>> Hi Med, >>>> >>>> It would still work for lw-4o6 and the unified CPE. All of the basic >>>> params for configuring lw4o6/MAP1:1 can be provisioned through the >>>> OPTION_MAP_BIND that is proposed in the unified CPE draft over DHCPv6. >>>> Additional DHCPv4 only options would be done via the DHCPv4oDHCPv6 >>method >>>> for both lw4o6 and MAP-E. >>>> >>>> We still need to agree on which option will be used for provisioning >>>>the >>>> address of the lwAFTR/MAP BR, however. There was some discussion on >>>>this >>>> on the SW ML last week, but no conclusion reached. >>>> >>>> >>>> Cheers, >>>> Ian >>>> >>>> On 15/04/2013 16:47, "mohamed.boucadair@orange.com" >>>> wrote: >>>> >>>>> Re-, >>>>> >>>>> Thanks for clarifying Ted. I must admit this is not what I understood >>>>> when I read draft-scskf-*. >>>>> >>>>> Does the same conclusion applies also for lw-4over6? (I'm naively >>>>> assuming, given the approach defined in draft-ietf-softwire-unified- >>cpe, >>>>> the same dhcpv6 to configure MAP will also be used lw-4over6) >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Ted Lemon [mailto:Ted.Lemon@nominum.com] >>>>>> Envoy=C3=A9 : lundi 15 avril 2013 16:39 >>>>>> =C3=80 : BOUCADAIR Mohamed OLNC/OLN >>>>>> Cc : Qi Sun; dhcwg@ietf.org; Softwires (softwires@ietf.org) >>>>>> Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over- >>dhcpv6 >>>>>> >>>>>> On Apr 15, 2013, at 10:27 AM, wrote: >>>>>>> Are you saying MAP is not a concerned with this draft and dhcpv6 >>>>>>>can >>be >>>>>> used for MAP? >>>>>> >>>>>> For configuring the MAP-E prefix and port set, yes. That was the >>>>>> discussion we had in Softwires in Orlando: cover the easy stuff with >>>>>> DHCPv6 >>>>>> (this is the existing DHCPv6 MAP option), and then if someone needs >>>>>> legacy >>>>>> IPv4 services or stateful address allocation, do it with >>>>>>DHCPv4-over- >>>>>> DHCPv6. >>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3448884428_1703902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLfz u93IyOxkx4a6Qhz4WbYNu50UMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDQxNTE5MjcwMFowDQYJKoZIhvcNAQEBBQAEggEAXBnpxV7ZuBSqZ0LseNF7 pbgtEc61Pr6Q2RX9C3+HNzgOywTHjcQBwGTl7MGiYY28ExPlw/pE+7Q5fasYn8lzrT/XzHH+ NKPLr/J99FPB7K7HVleXRdq+7CxwyktRr2AZA50XuJtqcnRWYhnWS2grzpD10x4ZpFLj/7bm MCya3X2XsDvJYNjDg90T5JwRQS8aYCadUpQWw7BRV5h7K57lOnizsPyDq2hInKYeDnnUFY/2 8BcQJvi39yJX6TAKcOuQnVu5nTM1v2AgjNkszPW1FvI7v4e/WEWOlAicc9qqh0oNr9ypZBH0 9YzoHcXR8/C9slOcyXafJ6L5p+ZwCU1yZw== --B_3448884428_1703902-- From volz@cisco.com Mon Apr 15 14:57:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741C621F8F26 for ; Mon, 15 Apr 2013 14:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDl9FDg67Nnu for ; Mon, 15 Apr 2013 14:57:56 -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 A78BF21F8F1C for ; Mon, 15 Apr 2013 14:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1789; q=dns/txt; s=iport; t=1366063076; x=1367272676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ev6idXGny8y2rSepeySipPRPrX82IitOwRm0v8e/1H0=; b=H5MfJ/QaQGjBlYyyRyvksOs+wVSGpcDwGoqITewvgcjzZKkfQlNZAyeK BOr9Ctfj08/v0Oe6utx0uPXmyfw+Z178f1jNU3YVpX1Ds2JBmReubKtRB zQ5gSUtqPeahk/rHfH+Eka85SLetqJv9RMsatHpxoIe1k0BUXVdlO7jS0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAJN2bFGtJV2d/2dsb2JhbABQgwY2wQWBBxZ0gh8BAQEDAQEBARodMQMLBQcEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCIgGBgy8BQSOZiYLBwaCWmEDqBaDC4Io X-IronPort-AV: E=Sophos;i="4.87,479,1363132800"; d="scan'208";a="199068004" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 15 Apr 2013 21:57:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3FLvulu031385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 21:57:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 16:57:55 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOe+X3k2MoTLQa0uUqsbeRb1B3pjX5kuA//+Tl9CAAHoRgP//4ACw Date: Mon, 15 Apr 2013 21:57:55 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18507028@xmb-rcd-x04.cisco.com> References: <0E7A43A57FCD74996D14FF6F1F13E304F@thehobsons.co.uk> <8D23D4052ABE7A4490E77B1A012B63077514939D@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E18506706@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630775149715@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775149715@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 21:57:57 -0000 >I know there's a lot of goo in the protocol to support this behavior, but = I haven't actually seen it used in the wild. Yes, it does happen. And, I suspect it will be more likely with DHCPv6 - an= d it gets interesting if there are ULAs or multiple prefixes from which to = assign (for renumbering?). > I could also use a co-author. Ah ... that means "supply text" :) We can discuss offline. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, April 15, 2013 12:50 PM To: Bernie Volz (volz) Cc: Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf On Apr 15, 2013, at 12:41 PM, Bernie Volz (volz) wrote: > Two other concepts that are often difficult for non-DHCP experts that sho= uld be considered are: > - Shared subnets - this is where multiple subnets are in use on one wire = for leasing Yup. > - Grouped subnets - this is where the giaddr or link-address are on a sub= net/prefix that is not being used for address assignment and thus needs to = be associated with another subnet/prefix. This is similar to the shared sub= net, but no leases are being assigned from one of the subnets (the "source"= subnet). Are there a lot of cases where this happens? I know there's a lot of goo = in the protocol to support this behavior, but I haven't actually seen it us= ed in the wild. > Do you want a call for adoption of this work? I think it would be a good = item for the WG to adopt. Yes, I was thinking a call for adoption would be a good idea. I could als= o use a co-author. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 15 15:11:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2582A21F93EA; Mon, 15 Apr 2013 15:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL8LlSZvY0Q1; Mon, 15 Apr 2013 15:11:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D0E2721F93E8; Mon, 15 Apr 2013 15:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1366063874; x=1367273474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o+YqBelVzj7TJM4epmVKc4yk5KUPUUqhxvEvh3kvYTs=; b=ZqbAfa1nNPh2u0BN/4OPlVF+DU8hHRerSZuiM/Rfc/X9LSNBQKVfByn6 ch6spShhynHsvTyZjQnsC/hyq77cxGyBZgvyVzfLONf2sIxGZKt47BSTk vlYMFc/QIse5ZpTpdNtFswgTDVVEZeBUNRjaObNIuXtW2aFHxCBBGBhw+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAJ16bFGtJV2b/2dsb2JhbABQgwaDZr1VDXoWdIIfAQEBBCMRRQwEAgEIEQQBAQMCBh0DAgICMBQBCAgCBAENBQiIDKlKkkyBI41DMQcGXYFLMmEDqBaCfg2CKA X-IronPort-AV: E=Sophos;i="4.87,479,1363132800"; d="scan'208";a="199059882" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 15 Apr 2013 22:11:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3FMBDFT005040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 22:11:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 17:11:13 -0500 From: "Bernie Volz (volz)" To: "Lee, Yiu" , "mohamed.boucadair@orange.com" , Qi Sun Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOg845rab7UHe6kuJY9MQXq4y6pjX1OSA Date: Mon, 15 Apr 2013 22:11:12 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E185070B8@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 22:11:15 -0000 VGhpcyBtaWdodCBiZSB3aGVyZSBkcmFmdC1yYWp0YXItZGhjLXY0Y29uZmlndXJhdGlvbiBjb21l cyBpbj8gV2Ugc3RpbGwgbmVlZCB0byBkZXRlcm1pbmUgd2hhdCB0byBkbyBhYm91dCB0aGF0IGRy YWZ0IGF0IHNvbWUgcG9pbnQgLSBJIHRoaW5rIHRoZSBwbGFuIHdhcyB0byB1cGRhdGUgaXQgc29t ZXRpbWUgYWZ0ZXIgYWRvcHRpbmcgdGhpcyB3b3JrIHRvIGluY2x1ZGUgaXQgYW5kIGFsc28gZG9j dW1lbnRpbmcgdGhlICJjb25zZW5zdXMiLg0KDQpXZSdsbCBuZWVkIHRvIHRha2UgYSBsb29rIGF0 IHRoZSBmdWxsIHNldCBvZiBkb2N1bWVudHMgd2UgbWlnaHQgbmVlZC4NCg0KSSB0aGluayB3ZSBu ZWVkIHRvIGJlIGNsZWFyIHRoYXQgREhDUHY2IGlzIE5FVkVSIHN1cHBvc2VkIHRvIGFzc2lnbiBh bmQgbWFuYWdlIHNwZWNpZmljIElQdjQgYWRkcmVzc2VzLiBXZSB3YW50IHRoYXQgdG8gYmUgZG9u ZSB2aWEgREhDUHY0Lg0KDQpNQVAgaXMgZGlmZmVyZW50IGluIHRoYXQgdGhlIERIQ1B2NiBzZXJ2 ZXIgaXMgbm90IGV4cGxpY2l0bHkgYXNzaWduaW5nIC8gbWFuYWdpbmcgYW55IElQdjQgYWRkcmVz c2VzIChvciBwb3J0IHNwYWNlKS4gVGhlIGNsaWVudCBkZXJpdmVzIGl0cyBJUHY0IGFkZHJlc3Mg dXNpbmcgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBNQVAgb3B0aW9uICh3aGljaCBpcyB0aGUgc2Ft ZSBzZXQgb2YgYml0cyBmb3IgbWFueSBjbGllbnRzKSBhbmQgaXRzIElQdjYgYWRkcmVzcy4gVGhp cyBpcyBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UuIEFuZCwgaXQgZG9lcyByZXN0cmljdCB3aGF0 IG90aGVyICdzZXJ2aWNlcycgKHN1Y2ggYXMgRE5TIHJlZ2lzdHJhdGlvbikgdGhlIERIQ1B2NiBu ZWVkcyB0byBkbyAoYW5kIHRoZSBjbGllbnQgY2FuIGJlIHByb3ZpZGVkKSBpbiB0ZXJtcyBvZiBJ UHY0LiBJbiB0aGUgTUFQIGNhc2UgdGhpcyBhbHNvIG1ha2VzIHNlbnNlIGFzIHRoZXJlIGlzbid0 IG9uZSBjbGllbnQgYmVoaW5kIHRoZSBhZGRyZXNzIChhcyB0aGUgcG9ydCBzcGFjZSBpcyBzaGFy ZWQpLg0KDQpBbmQsIGFsc28gd2h5IG90aGVyIGNhc2VzIGFyZSBsaWtlbHkgdG8gYmUgZGlmZmVy ZW50IGFuZCBuZWVkIG1vcmUgb2YgREhDUHY0IC0gYXMgRE5TIGFuZCBtb3JlIG1heSBiZSBuZWVk ZWQgdG8gcHJvdmlkZSB0aGUgY29tcGxldGUgSVB2NCBzdXBwb3J0IG92ZXIgSVB2Ni4NCg0KLSBC ZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRoY3dnLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVl LCBZaXUNClNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgMzoyNyBQTQ0KVG86IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb207IFFpIFN1bg0KQ2M6IHNvZnR3aXJlc0BpZXRmLm9yZzsgZGhj d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGhjd2ddIFtTb2Z0d2lyZXNdIEFkb3B0aW9uIGNh bGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ng0KDQpNZWQsDQoNCkkgYWdy ZWUgd2UgY2FuIHRhbGsgbW9yZSBtb3RpdmF0aW9ucyBpbiB0aGUgZHJhZnQuIEhvd2V2ZXIsDQpk cmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2IGRpc2N1c3NlcyBhIGdlbmVyaWMgc3Bl Y2lmaWNhdGlvbiBvZg0KREhDUHY0IG92ZXIgREhDUHY2LiBJIGFtIG5vdCBzdXJlIHdoYXQgd2Ug d2FudCB0byBtZW50aW9uIHNwZWNpZmljIHRvIE1BUCBvciBsdzRvdmVyNiBpbiB0aGlzIGRyYWZ0 Lg0KDQpUaGFua3MsDQpZaXUNCg0K From Ted.Lemon@nominum.com Mon Apr 15 15:34:09 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0821E803D; Mon, 15 Apr 2013 15:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIuZuMf4bcTN; Mon, 15 Apr 2013 15:34:08 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB2C21E803C; Mon, 15 Apr 2013 15:34:08 -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 DSNKUWyAX2fLOhkI1/FgJnPQI0ZGN4CGxp/u@postini.com; Mon, 15 Apr 2013 15:34:08 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 B0BF21B80F7; Mon, 15 Apr 2013 15:34:07 -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 91ADC190061; Mon, 15 Apr 2013 15:34:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 15:34:01 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOfBwAFtz57uTokG2qMobiPMkY5jX4/iAgAA78YCAAC3VAIAABl8A Date: Mon, 15 Apr 2013 22:34:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514A222@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E185070B8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E185070B8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <60546D4A331B674DB09C86B418F266BB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , Qi Sun , "Lee, Yiu" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 22:34:09 -0000 On Apr 15, 2013, at 6:11 PM, Bernie Volz (volz) wrote: > This might be where draft-rajtar-dhc-v4configuration comes in? We still n= eed to determine what to do about that draft at some point - I think the pl= an was to update it sometime after adopting this work to include it and als= o documenting the "consensus". The thought was that we would publish it as Informational, since it's certa= inly not intended to be deployed by anyone in the future, but has seen some= deployment already because some sites needed something to use for early de= ployment, and this was a pretty easy thing to implement. The document wou= ld have a big "informational only=97do not deploy" pasted on it so that nob= ody gets the wrong idea. Of course, the working group could also just decide to drop it=97I' replyin= g here to tell you what I recall from discussions we had in Orlando, not to= tell you what to do. From mohamed.boucadair@orange.com Mon Apr 15 22:39:36 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EB321F8F70; Mon, 15 Apr 2013 22:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9IhRrgrfvo3; Mon, 15 Apr 2013 22:39:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DC58321F9377; Mon, 15 Apr 2013 22:39:34 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8E0BC2DC163; Tue, 16 Apr 2013 07:39:33 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7159927C046; Tue, 16 Apr 2013 07:39:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 16 Apr 2013 07:39:33 +0200 From: To: "Lee, Yiu" , Qi Sun Date: Tue, 16 Apr 2013 07:39:31 +0200 Thread-Topic: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOg845rab7UHe6kuJY9MQXq4y6pjYVISQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EC3D25FC3@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.16.31526 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 05:39:36 -0000 SGkgWWl1LA0KDQpUZWQgYW5kIElhbiBwcm92aWRlZCBhbiBpbXBvcnRhbnQgY2xhcmlmaWNhdGlv biBvbiB0aGUgYXBwbGljYWJpbGl0eSBzY29wZSBvZiBkcmFmdC1zY3NrZi0qLiBJTUhPLCB0aGlz IHNob3VsZCBiZSByZWNvcmRlZCBpbiB0aGUgZHJhZnQgbm90IG9ubHkgaW4gbWFpbGluZyBsaXN0 IGFyY2hpdmVzLg0KDQpIYXZpbmcgYW4gYXBwbGljYWJpbGl0eSBzY29wZSBzZWN0aW9uIGluIHRo YXQgZHJhZnQgd291bGQgYmUgdXNlZnVsLg0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPkRlwqA6IExlZSwgWWl1IFttYWlsdG86WWl1X0xlZUBDYWJsZS5D b21jYXN0LmNvbV0NCj5FbnZvecOpwqA6IGx1bmRpIDE1IGF2cmlsIDIwMTMgMjE6MjcNCj7DgMKg OiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTjsgUWkgU3VuDQo+Q2PCoDogc29mdHdpcmVzQGll dGYub3JnOyBkaGN3Z0BpZXRmLm9yZw0KPk9iamV0wqA6IFJlOiBbU29mdHdpcmVzXSBbZGhjd2dd IEFkb3B0aW9uIGNhbGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC0NCj5vdmVyLWRoY3B2Ng0K Pg0KPk1lZCwNCj4NCj5JIGFncmVlIHdlIGNhbiB0YWxrIG1vcmUgbW90aXZhdGlvbnMgaW4gdGhl IGRyYWZ0LiBIb3dldmVyLA0KPmRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYgZGlz Y3Vzc2VzIGEgZ2VuZXJpYyBzcGVjaWZpY2F0aW9uIG9mDQo+REhDUHY0IG92ZXIgREhDUHY2LiBJ IGFtIG5vdCBzdXJlIHdoYXQgd2Ugd2FudCB0byBtZW50aW9uIHNwZWNpZmljIHRvIE1BUA0KPm9y IGx3NG92ZXI2IGluIHRoaXMgZHJhZnQuDQo+DQo+VGhhbmtzLA0KPllpdQ0KPg0KPg0KPg0KPk9u IDQvMTUvMTMgMTE6NTIgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPjxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4NCj4+UmUtLA0KPj4NCj4+VGhhbmtz IGZvciB0aGUgZXhwbGFuYXRpb25zLg0KPj4NCj4+SSBzdWdnZXN0IHRoZSBkb2N1bWVudCB0byBi ZSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIGNsYXJpZmljYXRpb25zIHlvdQ0KPj5wcm92aWRlZCBh bmQgYWxzbyB0aGUgb25lcyBwcm92aWRlZCBieSBJYW4gYW5kIFRlZCBmb3IgTUFQIGFuZCBMdzRv dmVyNg0KPj5jYXNlcy4gVGhlc2UgYXJlIGltcG9ydGFudCBpbnB1dHMuDQo+Pg0KPj5JIHdpdGhk cmF3IG15IG9iamVjdGlvbiB0byBoaXMgZG9jdW1lbnQuDQo+Pg0KPj5UaGFuayB5b3UgYWxsIGZv ciB5b3VyIHBhdGllbnQgZXhwbGFuYXRpb25zLg0KPj4NCj4+Q2hlZXJzLA0KPj5NZWQNCj4+DQo+ Pj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+PkRlIDogUWkgU3VuIFttYWlsdG86c3Vu cWkudGh1QGdtYWlsLmNvbV0NCj4+PkVudm95w6kgOiBsdW5kaSAxNSBhdnJpbCAyMDEzIDE3OjQ3 DQo+Pj7DgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Pj5DYyA6IGlhbi5mYXJyZXJA dGVsZWtvbS5kZTsgVGVkLkxlbW9uQG5vbWludW0uY29tOyBzb2Z0d2lyZXNAaWV0Zi5vcmc7DQo+ Pj5kaGN3Z0BpZXRmLm9yZw0KPj4+T2JqZXQgOiBSZTogW2RoY3dnXSBbU29mdHdpcmVzXSBBZG9w dGlvbiBjYWxsIG9uIGRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtDQo+Pj5vdmVyLWRoY3B2Ng0KPj4+ DQo+Pj4NCj4+PkRlYXIgTWVkLA0KPj4+DQo+Pj5JbiBNQVAtRSBwdXJlIHN0YXRlbGVzcyBtb2Rl LCBJUHY0IGFkZHJlc3MgKHByZWZpeCkgYW5kIHBvcnQgc2V0IGFyZQ0KPj4+cHJvdmlzaW9uZWQg aW4gTUFQIFJ1bGVzIGFzIGRlc2lnbmVkLiBCdXQgaW4gTUFQLUUgMToxIG1vZGUgYW5kIGx3NG92 ZXI2DQo+Pj53aGljaCBhcmUgKGtpbmQgb2YpIHN0YXRlZnVsLCBpdCBoYXMgdG8gdGFrZSBpbnRv IGNvbnNpZGVyYXRpb25zIGFib3V0DQo+Pj50aGUNCj4+PmxlYXNlIHRpbWUgZXRjLiBpc3N1ZXMu IEluIHRoaXMgY2FzZSwgSU1ITywgREhDUHY0IG92ZXIgREhDUHY2IGlzIG1vcmUNCj4+PnN1aXRh YmxlIGZvciBJUHY0IHJlbGF0ZWQgY29uZmlndXJhdGlvbnMuDQo+Pj4NCj4+PldoYXQncyBtb3Jl LCBESENQdjQtb3Zlci1ESENQdjYgaXMgbm90IG9ubHkgZGVzaWduZWQgdG8gZGVhbCB3aXRoIHRo ZQ0KPj4+b3B0aW9uIGlzc3VlcywgYnV0IGFsc28gdG8gaGFuZGxlIG90aGVyIGFyY2hpdGVjdHVy YWwgcHJvYmxlbXMgaW4NCj4+PnRyYW5zaXRpb24gKGFzIEJlcm5pZSBtZW50aW9uZWQgaW4gcHJl dmlvdXMgbWFpbCkuIFNvIEkgdGhpbmsNCj4+PkRIQ1B2NC1vdmVyLQ0KPj4+REhDUHY2IGlzIGhl bHBmdWwgZm9yIHRoZSBldm9sdmVtZW50IGluIERIQ1AgYXJjaGl0ZWN0dXJlLg0KPj4+DQo+Pj4N Cj4+PkJlc3QgUmVnYXJkcywNCj4+PlFpIFN1bg0KPj4+DQo+Pj4NCj4+Pk9uIDIwMTMtNC0xNSwg YXQg5LiL5Y2IMTE6MTMsIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4+PG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IEhpIElhbiwNCj4+Pj4N Cj4+Pj4gVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj4+Pj4gSSB1bmRlcnN0b29kIGZy b20geW91ciBhbnN3ZXI6IGRoY3B2NiB3aWxsIGJlIHVzZWQgZm9yIGJvdGggTUFQIGFuZA0KPj4+ bHc0b3ZlcjYgYW5kIGJvdGggZG9uJ3QgcmVxdWlyZSBkcmFmdC1zY3NrZi0qIGZvciBJUCBhZGRy ZXNzICsgcG9ydA0KPj4+cHJvdmlzaW9uaW5nLg0KPj4+Pg0KPj4+PiBHaXZlbiBjdXJyZW50bHkg bm8gYWRkaXRpb25hbCBkaGNwdjQgb25seSBvcHRpb25zIGlzIHJlcXVpcmVkIGZvciBhbnkNCj4+ Pj5vZg0KPj4+dGhlIHNvbHV0aW9ucyB3ZSBhcmUgZGlzY3Vzc2luZyBpbiBzb2Z0d2lyZSwgSSBk byBzdGlsbCB0aGluayBpdCBpcyBub3QNCj4+Pmp1c3RpZmllZCB0byB0YWtlIG9uIGEgc29sdXRp b24gZm9yIGEgcHJvYmxlbSB3aGljaCBtYXkgbm90IGV4aXN0Lg0KPj4+Pg0KPj4+PiBkcmFmdC1z Y3NrZi0qIHByb3Bvc2FsIGNhbiBiZSByZXZpdmVkIHdoZW4gdGhlcmUgaXMgYSByZWFsIG5lZWQg dG8NCj4+PnN1cHBvcnQgZGhjcHY0LW9ubHkgb3B0aW9ucy4gTm8/DQo+Pj4+DQo+Pj4+IENoZWVy cywNCj4+Pj4gTWVkDQo+Pj4+DQo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+ Pj4+IERlIDogaWFuLmZhcnJlckB0ZWxla29tLmRlIFttYWlsdG86aWFuLmZhcnJlckB0ZWxla29t LmRlXQ0KPj4+Pj4gRW52b3nDqSA6IGx1bmRpIDE1IGF2cmlsIDIwMTMgMTY6NTYNCj4+Pj4+IMOA IDogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE47IFRlZC5MZW1vbkBub21pbnVtLmNvbQ0KPj4+ Pj4gQ2MgOiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IGRoY3dnQGlldGYub3JnOyBzdW5xaS50aHVAZ21h aWwuY29tDQo+Pj4+PiBPYmpldCA6IFJlOiBbU29mdHdpcmVzXSBbZGhjd2ddIEFkb3B0aW9uIGNh bGwgb24NCj4+Pj4+ZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC0NCj4+Pj4+IG92ZXItZGhjcHY2DQo+ Pj4+Pg0KPj4+Pj4gSGkgTWVkLA0KPj4+Pj4NCj4+Pj4+IEl0IHdvdWxkIHN0aWxsIHdvcmsgZm9y IGx3LTRvNiBhbmQgdGhlIHVuaWZpZWQgQ1BFLiBBbGwgb2YgdGhlIGJhc2ljDQo+Pj4+PiBwYXJh bXMgZm9yIGNvbmZpZ3VyaW5nIGx3NG82L01BUDE6MSBjYW4gYmUgcHJvdmlzaW9uZWQgdGhyb3Vn aCB0aGUNCj4+Pj4+IE9QVElPTl9NQVBfQklORCB0aGF0IGlzIHByb3Bvc2VkIGluIHRoZSB1bmlm aWVkIENQRSBkcmFmdCBvdmVyIERIQ1B2Ni4NCj4+Pj4+IEFkZGl0aW9uYWwgREhDUHY0IG9ubHkg b3B0aW9ucyB3b3VsZCBiZSBkb25lIHZpYSB0aGUgREhDUHY0b0RIQ1B2Ng0KPj4+bWV0aG9kDQo+ Pj4+PiBmb3IgYm90aCBsdzRvNiBhbmQgTUFQLUUuDQo+Pj4+Pg0KPj4+Pj4gV2Ugc3RpbGwgbmVl ZCB0byBhZ3JlZSBvbiB3aGljaCBvcHRpb24gd2lsbCBiZSB1c2VkIGZvciBwcm92aXNpb25pbmcN Cj4+Pj4+dGhlDQo+Pj4+PiBhZGRyZXNzIG9mIHRoZSBsd0FGVFIvTUFQIEJSLCBob3dldmVyLiBU aGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9uDQo+Pj4+PnRoaXMNCj4+Pj4+IG9uIHRoZSBTVyBN TCBsYXN0IHdlZWssIGJ1dCBubyBjb25jbHVzaW9uIHJlYWNoZWQuDQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IENoZWVycywNCj4+Pj4+IElhbg0KPj4+Pj4NCj4+Pj4+IE9uIDE1LzA0LzIwMTMgMTY6NDcs ICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPj4+Pj4gPG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBSZS0sDQo+Pj4+Pj4NCj4+Pj4+PiBU aGFua3MgZm9yIGNsYXJpZnlpbmcgVGVkLiBJIG11c3QgYWRtaXQgdGhpcyBpcyBub3Qgd2hhdCBJ IHVuZGVyc3Rvb2QNCj4+Pj4+PiB3aGVuIEkgcmVhZCBkcmFmdC1zY3NrZi0qLg0KPj4+Pj4+DQo+ Pj4+Pj4gRG9lcyB0aGUgc2FtZSBjb25jbHVzaW9uIGFwcGxpZXMgYWxzbyBmb3IgbHctNG92ZXI2 PyAoSSdtIG5haXZlbHkNCj4+Pj4+PiBhc3N1bWluZywgZ2l2ZW4gdGhlIGFwcHJvYWNoIGRlZmlu ZWQgaW4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS11bmlmaWVkLQ0KPj4+Y3BlLA0KPj4+Pj4+IHRoZSBz YW1lIGRoY3B2NiB0byBjb25maWd1cmUgTUFQIHdpbGwgYWxzbyBiZSB1c2VkIGx3LTRvdmVyNikN Cj4+Pj4+Pg0KPj4+Pj4+IENoZWVycywNCj4+Pj4+PiBNZWQNCj4+Pj4+Pg0KPj4+Pj4+PiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+Pj4gRGUgOiBUZWQgTGVtb24gW21haWx0bzpU ZWQuTGVtb25Abm9taW51bS5jb21dDQo+Pj4+Pj4+IEVudm95w6kgOiBsdW5kaSAxNSBhdnJpbCAy MDEzIDE2OjM5DQo+Pj4+Pj4+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE4NCj4+Pj4+ Pj4gQ2MgOiBRaSBTdW47IGRoY3dnQGlldGYub3JnOyBTb2Z0d2lyZXMgKHNvZnR3aXJlc0BpZXRm Lm9yZykNCj4+Pj4+Pj4gT2JqZXQgOiBSZTogW2RoY3dnXSBBZG9wdGlvbiBjYWxsIG9uIGRyYWZ0 LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci0NCj4+PmRoY3B2Ng0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiBB cHIgMTUsIDIwMTMsIGF0IDEwOjI3IEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4g d3JvdGU6DQo+Pj4+Pj4+PiBBcmUgeW91IHNheWluZyBNQVAgaXMgbm90IGEgY29uY2VybmVkIHdp dGggdGhpcyBkcmFmdCBhbmQgZGhjcHY2DQo+Pj4+Pj4+PmNhbg0KPj4+YmUNCj4+Pj4+Pj4gdXNl ZCBmb3IgTUFQPw0KPj4+Pj4+Pg0KPj4+Pj4+PiBGb3IgY29uZmlndXJpbmcgdGhlIE1BUC1FIHBy ZWZpeCBhbmQgcG9ydCBzZXQsIHllcy4gICBUaGF0IHdhcyB0aGUNCj4+Pj4+Pj4gZGlzY3Vzc2lv biB3ZSBoYWQgaW4gU29mdHdpcmVzIGluIE9ybGFuZG86IGNvdmVyIHRoZSBlYXN5IHN0dWZmIHdp dGgNCj4+Pj4+Pj4gREhDUHY2DQo+Pj4+Pj4+ICh0aGlzIGlzIHRoZSBleGlzdGluZyBESENQdjYg TUFQIG9wdGlvbiksIGFuZCB0aGVuIGlmIHNvbWVvbmUgbmVlZHMNCj4+Pj4+Pj4gbGVnYWN5DQo+ Pj4+Pj4+IElQdjQgc2VydmljZXMgb3Igc3RhdGVmdWwgYWRkcmVzcyBhbGxvY2F0aW9uLCBkbyBp dCB3aXRoDQo+Pj4+Pj4+REhDUHY0LW92ZXItDQo+Pj4+Pj4+IERIQ1B2Ni4NCj4+Pj4+Pg0KPj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPj4+Pj4+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+Pj4+ DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IGRoY3dnIG1haWxpbmcgbGlzdA0KPj4+PiBkaGN3Z0BpZXRmLm9yZw0KPj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+Pg0KPj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5Tb2Z0d2lyZXMgbWFpbGluZyBs aXN0DQo+PlNvZnR3aXJlc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NvZnR3aXJlcw0K From Branimir.Rajtar@t.ht.hr Tue Apr 16 00:41:34 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD2E21F9679; Tue, 16 Apr 2013 00:41:34 -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 sfeZQX871VBL; Tue, 16 Apr 2013 00:41:33 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D7B0E21F9676; Tue, 16 Apr 2013 00:41:31 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Tue, 16 Apr 2013 09:09:24 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 66f4_9c5c_0c6c2b54_a669_11e2_8cac_00219b931f47; Tue, 16 Apr 2013 09:41:28 +0200 Received: (private information removed) Tue, 16 Apr 2013 09:41:28 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Tue, 16 Apr 2013 09:41:28 +0200 From: Branimir Rajtar To: Ted Lemon , "Bernie Volz (volz)" Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOg845rab7UHe6kuJY9MQXq4y6pjX1OSA///oHACAALlHsA== Date: Tue, 16 Apr 2013 07:41:27 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0142651D@S2010EXCH1.ad.local> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E185070B8@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077514A222@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514A222@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2013 07:41:28.0535 (UTC) FILETIME=[CE32E670:01CE3A75] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , Qi Sun , "Lee, Yiu" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 07:41:34 -0000 SGksCgpKdXN0IGEgc2hvcnQgaW5mbyBvbiB0aGUgdGhlIGRyYWZ0LXJhanRhciB3b3JrLiBJYW4g YW5kIEkgaGF2ZSBiZWVuIHdhdGNoaW5nIGNsb3NlbHkgdGhlIGRpc2N1c3Npb25zIGhlcmUgKHdp dGggSWFuIHRha2luZyB0aGUgbW9yZSBhY3RpdmUgcm9sZSkgYW5kIHdlJ3JlIHVwZGF0aW5nIHRo ZSBkcmFmdCBhY2NvcmRpbmdseS4gV2UgaG9wZSB0byBiZSBhYmxlIHRoZSBwdWJsaXNoIHRoZSBu ZXcgZHJhZnQgd2hpY2ggd2lsbCBpbmNsdWRlIGRoY3A0LW92ZXItZGhjcDYgYW5kIHNvbWUgb3Ro ZXIgY2hhbmdlcyBsYXRlciB0aGlzIHdlZWsgYW5kIG1ha2UgYSBjYWxsIGZvciBhZG9wdGlvbi4g V2UgZmVlbCB0aGF0IFRlZCdzIGFwcHJvYWNoIG9mICJpbmZvcm1hdGlvbmFsLW9ubHkiIGlzIHRo ZSB3YXkgdG8gZ28uCgpCUiwKQnJhbmltaXIKCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpG cm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbgpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNiwgMjAxMyAx MjozNCBBTQpUbzogQmVybmllIFZvbHogKHZvbHopCkNjOiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IGRo Y3dnQGlldGYub3JnOyBRaSBTdW47IExlZSwgWWl1ClN1YmplY3Q6IFJlOiBbZGhjd2ddIFtTb2Z0 d2lyZXNdIEFkb3B0aW9uIGNhbGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2 NgoKT24gQXByIDE1LCAyMDEzLCBhdCA2OjExIFBNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpA Y2lzY28uY29tPiB3cm90ZToKPiBUaGlzIG1pZ2h0IGJlIHdoZXJlIGRyYWZ0LXJhanRhci1kaGMt djRjb25maWd1cmF0aW9uIGNvbWVzIGluPyBXZSBzdGlsbCBuZWVkIHRvIGRldGVybWluZSB3aGF0 IHRvIGRvIGFib3V0IHRoYXQgZHJhZnQgYXQgc29tZSBwb2ludCAtIEkgdGhpbmsgdGhlIHBsYW4g d2FzIHRvIHVwZGF0ZSBpdCBzb21ldGltZSBhZnRlciBhZG9wdGluZyB0aGlzIHdvcmsgdG8gaW5j bHVkZSBpdCBhbmQgYWxzbyBkb2N1bWVudGluZyB0aGUgImNvbnNlbnN1cyIuCgoKVGhlIHRob3Vn aHQgd2FzIHRoYXQgd2Ugd291bGQgcHVibGlzaCBpdCBhcyBJbmZvcm1hdGlvbmFsLCBzaW5jZSBp dCdzIGNlcnRhaW5seSBub3QgaW50ZW5kZWQgdG8gYmUgZGVwbG95ZWQgYnkgYW55b25lIGluIHRo ZSBmdXR1cmUsIGJ1dCBoYXMgc2VlbiBzb21lIGRlcGxveW1lbnQgYWxyZWFkeSBiZWNhdXNlIHNv bWUgc2l0ZXMgbmVlZGVkIHNvbWV0aGluZyB0byB1c2UgZm9yIGVhcmx5IGRlcGxveW1lbnQsIGFu ZCB0aGlzIHdhcyBhIHByZXR0eSBlYXN5IHRoaW5nIHRvIGltcGxlbWVudC4gICBUaGUgZG9jdW1l bnQgd291bGQgaGF2ZSBhIGJpZyAiaW5mb3JtYXRpb25hbCBvbmx5LWRvIG5vdCBkZXBsb3kiIHBh c3RlZCBvbiBpdCBzbyB0aGF0IG5vYm9keSBnZXRzIHRoZSB3cm9uZyBpZGVhLgoKT2YgY291cnNl LCB0aGUgd29ya2luZyBncm91cCBjb3VsZCBhbHNvIGp1c3QgZGVjaWRlIHRvIGRyb3AgaXQtSScg cmVwbHlpbmcgaGVyZSB0byB0ZWxsIHlvdSB3aGF0IEkgcmVjYWxsIGZyb20gZGlzY3Vzc2lvbnMg d2UgaGFkIGluIE9ybGFuZG8sIG5vdCB0byB0ZWxsIHlvdSB3aGF0IHRvIGRvLgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFpbGluZyBsaXN0 CmRoY3dnQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhj d2cKCgo8SFRNTD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQpJ WkpBVkEgTyBPRFJJQ0FOSlUgT0RHT1ZPUk5PU1RJOiBTYWRyxb5haiBvdmUgcG9ydWtlIGkgZXZl bnR1YWxubyBwcmlsb8W+ZW5paCBkYXRvdGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFtaWplbmplbiBq ZSBzYW1vIG9zb2JhbWEgaWxpIHN1Ympla3RpbWEga29qaSBzdSBuYXZlZGVuaSB1IGFkcmVzaS4g VWtvbGlrbyBzdGUgcHJpbWlsaSBvdnUgcG9ydWt1IGdyZcWha29tLCBtb2xpbW8gVmFzLCBvYmF2 aWplc3RpdGUgcG/FoWlsamF0ZWxqYSwgYSBwb3J1a3UgaSBzdmUgbmplbmUgcHJpdml0a2Ugb2Rt YWgsIGJleiDEjWl0YW5qYSwgdHJham5vIHVrbG9uaXRlIHMgcmHEjXVuYWxhLiBCaWxvIGtha3Zv IHByZW5vxaFlbmplLCBrb3BpcmFuamUgaWxpIGRpc3RyaWJ1Y2lqYSBpbmZvcm1hY2lqYSBzYWRy xb5hbmloIHUgcG9ydWNpIHRyZcSHaW0gb3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW/FvmUgYml0 aSB6YWtvbnNraSBrYcW+bmppdm8uIFNhZHLFvmFqLCBzdGF2b3ZpIGkgbWnFoWxqZW5qYSBpem5l c2VuaSB1IHBvcnVjaSBzdSBhdXRvcm92aSBpIG5lIHByZWRzdGF2bGphanUgbnXFvm5vIHN0YXZv dmUgSFQgLSBIcnZhdHNraWggdGVsZWtvbXVuaWthY2lqYSBkLmQuIEhUIG5lIHByaWh2YcSHYSBu aWtha3Z1IG9kZ292b3Jub3N0IHphIGV2ZW50dWFsbnUgxaF0ZXR1IG5hc3RhbHUgcHJpbWl0a29t IG92ZSBwb3J1a2UgaSBwcmlsb2dhIHNhZHLFvmFuaWggdSBwb3J1Y2kuDQoNCjwvRk9OVD48L1A+ PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KIERJU0NMQUlNRVI6 VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYXMgd2VsbCBhcyBhbnkgZmlsZXMgYXR0YWNoZWQg dG8gaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciBpbmRpdmlkdWFs cyBvciBlbnRpdGllcyB3aGljaCB0aGV5IGFyZSBhZGRyZXNzZWQgdG8uIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBwZXJtYW5lbnRseSByZW1vdmUgdGhlIG1lc3NhZ2UgYW5kIGFsbCBhdHRhY2hlZCBm aWxlcyBmcm9tIHRoZSBjb21wdXRlci4gQW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJp YnV0aW9uIG9mIGFsbCBvciBhIHBhcnQgb2YgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiB0 byBvciBieSB0aGlyZCBwYXJ0aWVzIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g UGxlYXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJlc2VudGVkIGluIHRoaXMg bWVzc2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3Nh cmlseSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBDcm9hdGlhbiBUZWxlY29t IEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciBhbnkg cG90ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFuZCBmaWxlcyBhdHRhY2hl ZCB0byBpdC4NCg0KPC9GT05UPjwvUD48L0hUTUw+Cg== From chenycmx@gmail.com Tue Apr 16 01:41:16 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D617F21F968C; Tue, 16 Apr 2013 01:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvmVtsc0nnKd; Tue, 16 Apr 2013 01:41:15 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 82CD621F968A; Tue, 16 Apr 2013 01:41:15 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa11so224319pad.41 for ; Tue, 16 Apr 2013 01:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:reply-to:subject:references:x-priority :x-guid:x-has-attach:x-mailer:mime-version:message-id:content-type; bh=LRaB3TGIZREukmFqbK6dSBvFrua9bblju22xP6VuZM0=; b=s62mFJg4WrIGJWBYVQfMDpzNVhTBrkPxeiF/PIWQLDtlW0vnId8CBQZuVzdC2mBAKG aTxOp6/UEgmDRn2HaJPIONTATOBLtbCm+bw0udP/SW86UI8GKzfyZQe0oMtnu1rpXmwC 1KVRlY63Pz8yUYk8NbVDjEuuxIUMnN/53/D1Hebllum1wqGcj3L8jH2PAicWtRZEW20W VLFn/0j5N6LOBO3I8gdHARDvGCGTyr7oK4J4ynszJrFpF7Q6zQg1qLVXQMedncRZDV3+ +38La2YHsW+qsWMqapXwo+Dbfl204pU46fXKjA6eyv6+Wzok6zpNBsQFHpFOkYmAky97 tL3A== X-Received: by 10.68.184.132 with SMTP id eu4mr1863596pbc.87.1366101675202; Tue, 16 Apr 2013 01:41:15 -0700 (PDT) Received: from user-902eaffedc ([166.111.68.231]) by mx.google.com with ESMTPS id ak5sm1826336pac.4.2013.04.16.01.41.08 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 16 Apr 2013 01:41:13 -0700 (PDT) Date: Tue, 16 Apr 2013 16:41:10 +0800 From: "Yuchi Chen" To: med , =?utf-8?B?TGVlLCBZaXU=?= , "Qi Sun" References: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EC3D25FC3@PUEXCB1B.nanterre.francetelecom.fr> X-Priority: 3 X-GUID: 84188D3A-57DC-4CAD-A277-49BC610151A0 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2013041616410567161713@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart180462127502_=----" X-Mailman-Approved-At: Tue, 16 Apr 2013 04:43:51 -0700 Cc: softwires WG , "dhcwg@ietf.org" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 08:41:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart180462127502_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWVkIGFuZCBZaXUsDQoNCkkgYWdyZWUgd2l0aCB5b3UsIGFuZCBhbHNvIEkgdGhpbmsgaXQn cyBiZXR0ZXIgaWYgbm90IGFueSBzcGVjaWZpYyBzb2x1dGlvbiBpcyBtZW50aW9uZWQgaW4gZHJh ZnQtc2Nza2YtKiwgYXMgdGhpcyBkcmFmdCBpcyBtZWFudCB0byBiZSBhIGdlbmVyYWwgc29sdXRp b24uIE1heWJlIHRoZSBjbGFyaWZpY2F0aW9uIG9uIGFwcGxpY2FiaWxpdHkgc2NvcGUgY291bGQg YmUgbGlrZSB0aGlzOiAidGhpcyBzb2x1dGlvbiBpcyBtb3N0IHJlY29tbWVuZGVkIGZvciBkeW5h bWljIElQdjQgYWxsb2NhdGlvbiBhbmQgSVB2NCBwYXJhbSBwcm92aXNpb25pbmciLiBXZSBjYW4g YWRkIGEgc2VjdGlvbiB0byBzYXkgdGhhdCwgb3IganVzdCBzYXkgdGhhdCBpbiB0aGUgSW50cm9k dWN0aW9uIHNlY3Rpb24gYXMgdGhlIHN1cHBsZW1lbnQgb2YgdGhlIG1vdGl2YXRpb24gc3RhdGVt ZW50IChpLmUuICJJbiBhZGRpdGlvbiB0byBwcm92aWRpbmcgSVB2NCBhZGRyZXNzZXMgZm9yIGNs aWVudHMgb2YgdGhpcyBzZXJ2aWNlLCBvdGhlciBJUHY0IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVy cyBtYXkgYWxzbyBuZWVkIHRvIGJlIHByb3ZpZGVkIC4uLiIpLg0KDQpCZXN0IHJlZ2FyZHMhDQoN Cg0KDQpZdWNoaSBDaGVuIA0KDQpGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQpE YXRlOiAyMDEzLTA0LTE2IDEzOjM5DQpUbzogTGVlLCBZaXU7IFFpIFN1bg0KQ0M6IHNvZnR3aXJl c0BpZXRmLm9yZzsgZGhjd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBbZGhj d2ddIEFkb3B0aW9uIGNhbGwgb24gZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ng0K SGkgWWl1LA0KDQpUZWQgYW5kIElhbiBwcm92aWRlZCBhbiBpbXBvcnRhbnQgY2xhcmlmaWNhdGlv biBvbiB0aGUgYXBwbGljYWJpbGl0eSBzY29wZSBvZiBkcmFmdC1zY3NrZi0qLiBJTUhPLCB0aGlz IHNob3VsZCBiZSByZWNvcmRlZCBpbiB0aGUgZHJhZnQgbm90IG9ubHkgaW4gbWFpbGluZyBsaXN0 IGFyY2hpdmVzLg0KDQpIYXZpbmcgYW4gYXBwbGljYWJpbGl0eSBzY29wZSBzZWN0aW9uIGluIHRo YXQgZHJhZnQgd291bGQgYmUgdXNlZnVsLg0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPkRlIDogTGVlLCBZaXUgW21haWx0bzpZaXVfTGVlQENhYmxlLkNv bWNhc3QuY29tXQ0KPkVudm95w6kgOiBsdW5kaSAxNSBhdnJpbCAyMDEzIDIxOjI3DQo+w4AgOiBC T1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTjsgUWkgU3VuDQo+Q2MgOiBzb2Z0d2lyZXNAaWV0Zi5v cmc7IGRoY3dnQGlldGYub3JnDQo+T2JqZXQgOiBSZTogW1NvZnR3aXJlc10gW2RoY3dnXSBBZG9w dGlvbiBjYWxsIG9uIGRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtDQo+b3Zlci1kaGNwdjYNCj4NCj5N ZWQsDQo+DQo+SSBhZ3JlZSB3ZSBjYW4gdGFsayBtb3JlIG1vdGl2YXRpb25zIGluIHRoZSBkcmFm dC4gSG93ZXZlciwNCj5kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2IGRpc2N1c3Nl cyBhIGdlbmVyaWMgc3BlY2lmaWNhdGlvbiBvZg0KPkRIQ1B2NCBvdmVyIERIQ1B2Ni4gSSBhbSBu b3Qgc3VyZSB3aGF0IHdlIHdhbnQgdG8gbWVudGlvbiBzcGVjaWZpYyB0byBNQVANCj5vciBsdzRv dmVyNiBpbiB0aGlzIGRyYWZ0Lg0KPg0KPlRoYW5rcywNCj5ZaXUNCj4NCj4NCj4NCj5PbiA0LzE1 LzEzIDExOjUyIEFNLCAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSINCj48bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+DQo+PlJlLSwNCj4+DQo+PlRoYW5rcyBmb3Ig dGhlIGV4cGxhbmF0aW9ucy4NCj4+DQo+Pkkgc3VnZ2VzdCB0aGUgZG9jdW1lbnQgdG8gYmUgdXBk YXRlZCB0byByZWZsZWN0IHRoZSBjbGFyaWZpY2F0aW9ucyB5b3UNCj4+cHJvdmlkZWQgYW5kIGFs c28gdGhlIG9uZXMgcHJvdmlkZWQgYnkgSWFuIGFuZCBUZWQgZm9yIE1BUCBhbmQgTHc0b3ZlcjYN Cj4+Y2FzZXMuIFRoZXNlIGFyZSBpbXBvcnRhbnQgaW5wdXRzLg0KPj4NCj4+SSB3aXRoZHJhdyBt eSBvYmplY3Rpb24gdG8gaGlzIGRvY3VtZW50Lg0KPj4NCj4+VGhhbmsgeW91IGFsbCBmb3IgeW91 ciBwYXRpZW50IGV4cGxhbmF0aW9ucy4NCj4+DQo+PkNoZWVycywNCj4+TWVkDQo+Pg0KPj4+LS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj5EZSA6IFFpIFN1biBbbWFpbHRvOnN1bnFpLnRo dUBnbWFpbC5jb21dDQo+Pj5FbnZvecOpIDogbHVuZGkgMTUgYXZyaWwgMjAxMyAxNzo0Nw0KPj4+ w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTg0KPj4+Q2MgOiBpYW4uZmFycmVyQHRlbGVr b20uZGU7IFRlZC5MZW1vbkBub21pbnVtLmNvbTsgc29mdHdpcmVzQGlldGYub3JnOw0KPj4+ZGhj d2dAaWV0Zi5vcmcNCj4+Pk9iamV0IDogUmU6IFtkaGN3Z10gW1NvZnR3aXJlc10gQWRvcHRpb24g Y2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LQ0KPj4+b3Zlci1kaGNwdjYNCj4+Pg0KPj4+ DQo+Pj5EZWFyIE1lZCwNCj4+Pg0KPj4+SW4gTUFQLUUgcHVyZSBzdGF0ZWxlc3MgbW9kZSwgSVB2 NCBhZGRyZXNzIChwcmVmaXgpIGFuZCBwb3J0IHNldCBhcmUNCj4+PnByb3Zpc2lvbmVkIGluIE1B UCBSdWxlcyBhcyBkZXNpZ25lZC4gQnV0IGluIE1BUC1FIDE6MSBtb2RlIGFuZCBsdzRvdmVyNg0K Pj4+d2hpY2ggYXJlIChraW5kIG9mKSBzdGF0ZWZ1bCwgaXQgaGFzIHRvIHRha2UgaW50byBjb25z aWRlcmF0aW9ucyBhYm91dA0KPj4+dGhlDQo+Pj5sZWFzZSB0aW1lIGV0Yy4gaXNzdWVzLiBJbiB0 aGlzIGNhc2UsIElNSE8sIERIQ1B2NCBvdmVyIERIQ1B2NiBpcyBtb3JlDQo+Pj5zdWl0YWJsZSBm b3IgSVB2NCByZWxhdGVkIGNvbmZpZ3VyYXRpb25zLg0KPj4+DQo+Pj5XaGF0J3MgbW9yZSwgREhD UHY0LW92ZXItREhDUHY2IGlzIG5vdCBvbmx5IGRlc2lnbmVkIHRvIGRlYWwgd2l0aCB0aGUNCj4+ Pm9wdGlvbiBpc3N1ZXMsIGJ1dCBhbHNvIHRvIGhhbmRsZSBvdGhlciBhcmNoaXRlY3R1cmFsIHBy b2JsZW1zIGluDQo+Pj50cmFuc2l0aW9uIChhcyBCZXJuaWUgbWVudGlvbmVkIGluIHByZXZpb3Vz IG1haWwpLiBTbyBJIHRoaW5rDQo+Pj5ESENQdjQtb3Zlci0NCj4+PkRIQ1B2NiBpcyBoZWxwZnVs IGZvciB0aGUgZXZvbHZlbWVudCBpbiBESENQIGFyY2hpdGVjdHVyZS4NCj4+Pg0KPj4+DQo+Pj5C ZXN0IFJlZ2FyZHMsDQo+Pj5RaSBTdW4NCj4+Pg0KPj4+DQo+Pj5PbiAyMDEzLTQtMTUsIGF0IOS4 i+WNiDExOjEzLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+Pjxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4+Pg0KPj4+PiBIaSBJYW4sDQo+Pj4+DQo+Pj4+ IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uDQo+Pj4+IEkgdW5kZXJzdG9vZCBmcm9tIHlv dXIgYW5zd2VyOiBkaGNwdjYgd2lsbCBiZSB1c2VkIGZvciBib3RoIE1BUCBhbmQNCj4+Pmx3NG92 ZXI2IGFuZCBib3RoIGRvbid0IHJlcXVpcmUgZHJhZnQtc2Nza2YtKiBmb3IgSVAgYWRkcmVzcyAr IHBvcnQNCj4+PnByb3Zpc2lvbmluZy4NCj4+Pj4NCj4+Pj4gR2l2ZW4gY3VycmVudGx5IG5vIGFk ZGl0aW9uYWwgZGhjcHY0IG9ubHkgb3B0aW9ucyBpcyByZXF1aXJlZCBmb3IgYW55DQo+Pj4+b2YN Cj4+PnRoZSBzb2x1dGlvbnMgd2UgYXJlIGRpc2N1c3NpbmcgaW4gc29mdHdpcmUsIEkgZG8gc3Rp bGwgdGhpbmsgaXQgaXMgbm90DQo+Pj5qdXN0aWZpZWQgdG8gdGFrZSBvbiBhIHNvbHV0aW9uIGZv ciBhIHByb2JsZW0gd2hpY2ggbWF5IG5vdCBleGlzdC4NCj4+Pj4NCj4+Pj4gZHJhZnQtc2Nza2Yt KiBwcm9wb3NhbCBjYW4gYmUgcmV2aXZlZCB3aGVuIHRoZXJlIGlzIGEgcmVhbCBuZWVkIHRvDQo+ Pj5zdXBwb3J0IGRoY3B2NC1vbmx5IG9wdGlvbnMuIE5vPw0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+ Pj4+IE1lZA0KPj4+Pg0KPj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+PiBE ZSA6IGlhbi5mYXJyZXJAdGVsZWtvbS5kZSBbbWFpbHRvOmlhbi5mYXJyZXJAdGVsZWtvbS5kZV0N Cj4+Pj4+IEVudm95w6kgOiBsdW5kaSAxNSBhdnJpbCAyMDEzIDE2OjU2DQo+Pj4+PiDDgCA6IEJP VUNBREFJUiBNb2hhbWVkIE9MTkMvT0xOOyBUZWQuTGVtb25Abm9taW51bS5jb20NCj4+Pj4+IENj IDogc29mdHdpcmVzQGlldGYub3JnOyBkaGN3Z0BpZXRmLm9yZzsgc3VucWkudGh1QGdtYWlsLmNv bQ0KPj4+Pj4gT2JqZXQgOiBSZTogW1NvZnR3aXJlc10gW2RoY3dnXSBBZG9wdGlvbiBjYWxsIG9u DQo+Pj4+PmRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtDQo+Pj4+PiBvdmVyLWRoY3B2Ng0KPj4+Pj4N Cj4+Pj4+IEhpIE1lZCwNCj4+Pj4+DQo+Pj4+PiBJdCB3b3VsZCBzdGlsbCB3b3JrIGZvciBsdy00 bzYgYW5kIHRoZSB1bmlmaWVkIENQRS4gQWxsIG9mIHRoZSBiYXNpYw0KPj4+Pj4gcGFyYW1zIGZv ciBjb25maWd1cmluZyBsdzRvNi9NQVAxOjEgY2FuIGJlIHByb3Zpc2lvbmVkIHRocm91Z2ggdGhl DQo+Pj4+PiBPUFRJT05fTUFQX0JJTkQgdGhhdCBpcyBwcm9wb3NlZCBpbiB0aGUgdW5pZmllZCBD UEUgZHJhZnQgb3ZlciBESENQdjYuDQo+Pj4+PiBBZGRpdGlvbmFsIERIQ1B2NCBvbmx5IG9wdGlv bnMgd291bGQgYmUgZG9uZSB2aWEgdGhlIERIQ1B2NG9ESENQdjYNCj4+Pm1ldGhvZA0KPj4+Pj4g Zm9yIGJvdGggbHc0bzYgYW5kIE1BUC1FLg0KPj4+Pj4NCj4+Pj4+IFdlIHN0aWxsIG5lZWQgdG8g YWdyZWUgb24gd2hpY2ggb3B0aW9uIHdpbGwgYmUgdXNlZCBmb3IgcHJvdmlzaW9uaW5nDQo+Pj4+ PnRoZQ0KPj4+Pj4gYWRkcmVzcyBvZiB0aGUgbHdBRlRSL01BUCBCUiwgaG93ZXZlci4gVGhlcmUg d2FzIHNvbWUgZGlzY3Vzc2lvbiBvbg0KPj4+Pj50aGlzDQo+Pj4+PiBvbiB0aGUgU1cgTUwgbGFz dCB3ZWVrLCBidXQgbm8gY29uY2x1c2lvbiByZWFjaGVkLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBD aGVlcnMsDQo+Pj4+PiBJYW4NCj4+Pj4+DQo+Pj4+PiBPbiAxNS8wNC8yMDEzIDE2OjQ3LCAibW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSINCj4+Pj4+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gUmUtLA0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtz IGZvciBjbGFyaWZ5aW5nIFRlZC4gSSBtdXN0IGFkbWl0IHRoaXMgaXMgbm90IHdoYXQgSSB1bmRl cnN0b29kDQo+Pj4+Pj4gd2hlbiBJIHJlYWQgZHJhZnQtc2Nza2YtKi4NCj4+Pj4+Pg0KPj4+Pj4+ IERvZXMgdGhlIHNhbWUgY29uY2x1c2lvbiBhcHBsaWVzIGFsc28gZm9yIGx3LTRvdmVyNj8gKEkn bSBuYWl2ZWx5DQo+Pj4+Pj4gYXNzdW1pbmcsIGdpdmVuIHRoZSBhcHByb2FjaCBkZWZpbmVkIGlu IGRyYWZ0LWlldGYtc29mdHdpcmUtdW5pZmllZC0NCj4+PmNwZSwNCj4+Pj4+PiB0aGUgc2FtZSBk aGNwdjYgdG8gY29uZmlndXJlIE1BUCB3aWxsIGFsc28gYmUgdXNlZCBsdy00b3ZlcjYpDQo+Pj4+ Pj4NCj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4gTWVkDQo+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+Pj4+IERlIDogVGVkIExlbW9uIFttYWlsdG86VGVkLkxl bW9uQG5vbWludW0uY29tXQ0KPj4+Pj4+PiBFbnZvecOpIDogbHVuZGkgMTUgYXZyaWwgMjAxMyAx NjozOQ0KPj4+Pj4+PiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Pj4+Pj4+IENj IDogUWkgU3VuOyBkaGN3Z0BpZXRmLm9yZzsgU29mdHdpcmVzIChzb2Z0d2lyZXNAaWV0Zi5vcmcp DQo+Pj4+Pj4+IE9iamV0IDogUmU6IFtkaGN3Z10gQWRvcHRpb24gY2FsbCBvbiBkcmFmdC1zY3Nr Zi1kaGMtZGhjcHY0LW92ZXItDQo+Pj5kaGNwdjYNCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gQXByIDE1 LCAyMDEzLCBhdCAxMDoyNyBBTSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3Rl Og0KPj4+Pj4+Pj4gQXJlIHlvdSBzYXlpbmcgTUFQIGlzIG5vdCBhIGNvbmNlcm5lZCB3aXRoIHRo aXMgZHJhZnQgYW5kIGRoY3B2Ng0KPj4+Pj4+Pj5jYW4NCj4+PmJlDQo+Pj4+Pj4+IHVzZWQgZm9y IE1BUD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gRm9yIGNvbmZpZ3VyaW5nIHRoZSBNQVAtRSBwcmVmaXgg YW5kIHBvcnQgc2V0LCB5ZXMuICAgVGhhdCB3YXMgdGhlDQo+Pj4+Pj4+IGRpc2N1c3Npb24gd2Ug aGFkIGluIFNvZnR3aXJlcyBpbiBPcmxhbmRvOiBjb3ZlciB0aGUgZWFzeSBzdHVmZiB3aXRoDQo+ Pj4+Pj4+IERIQ1B2Ng0KPj4+Pj4+PiAodGhpcyBpcyB0aGUgZXhpc3RpbmcgREhDUHY2IE1BUCBv cHRpb24pLCBhbmQgdGhlbiBpZiBzb21lb25lIG5lZWRzDQo+Pj4+Pj4+IGxlZ2FjeQ0KPj4+Pj4+ PiBJUHY0IHNlcnZpY2VzIG9yIHN0YXRlZnVsIGFkZHJlc3MgYWxsb2NhdGlvbiwgZG8gaXQgd2l0 aA0KPj4+Pj4+PkRIQ1B2NC1vdmVyLQ0KPj4+Pj4+PiBESENQdjYuDQo+Pj4+Pj4NCj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IFNv ZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPj4+Pg0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBk aGN3ZyBtYWlsaW5nIGxpc3QNCj4+Pj4gZGhjd2dAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPj4NCj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0K Pj5Tb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb2Z0d2lyZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart180462127502_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Med and Yiu,
 
I agree with you, and also I think it's better if not = any=20 specific solution is mentioned in draft-scskf-*, as this draft is meant to= be a=20 general solution. Maybe the clarification on applicability scope coul= d be=20 like this: "this solution is most recommended for dynamic IPv4=20 allocation and IPv4 param provisioning". We can add a section to say that,= or=20 just say that in the Introduction section as the supplement of t= he=20 motivation statement (i.e. "In addition to providing IPv4 addresses for cl= ients=20 of this service, other IPv4 configuration parameters may also need to be=20 provided ...").
 
Best=20 regards!
Yuchi=20 Chen 
 
From: mohamed.boucadair@orange.com<= /A>
Date: 2013-04-16 13:39
To: Lee, Yiu= ; Qi Sun
Subject: Re: [Softwires] [dhcwg] Adoption call on=20 draft-scskf-dhc-dhcpv4-over-dhcpv6
Hi Yiu,
 
Ted and Ian provided an important clari= fication on the applicability scope of draft= -scskf-*. IMHO, this should be recorded in&n= bsp;the draft not only in mailing list = archives.
 
Having an applicability scope section in&nbs= p;that draft would be useful.
 
Cheers,
Med
 
>-----Message d'origine-----
>De : Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.c= om]
>Envoy=C3=A9 : lundi 15 avril 2013 2= 1:27
>=C3=80 : BOUCADAIR Mohamed OLNC/OLN; Qi&= nbsp;Sun
>Cc : softwires@ietf.org; dhcwg@ietf.org
>Objet : Re: [Softwires] [dhcwg] Adoption=  call on draft-scskf-dhc-dhcpv4-
>over-dhcpv6
>
>Med,
>
>I agree we can talk more motivation= s in the draft. However,
>draft-scskf-dhc-dhcpv4-over-dhcpv6 discusses a gen= eric specification of
>DHCPv4 over DHCPv6. I am not sure&n= bsp;what we want to mention specific to = ;MAP
>or lw4over6 in this draft.
>
>Thanks,
>Yiu
>
>
>
>On 4/15/13 11:52 AM, "mohamed.boucadair@orang= e.com"
><mohamed.boucadair@orange.com> wrote:
>
>>Re-,
>>
>>Thanks for the explanations.
>>
>>I suggest the document to be up= dated to reflect the clarifications you
>>provided and also the ones provided&= nbsp;by Ian and Ted for MAP and Lw4over= 6
>>cases. These are important inputs.
>>
>>I withdraw my objection to his = document.
>>
>>Thank you all for your patient = explanations.
>>
>>Cheers,
>>Med
>>
>>>-----Message d'origine-----
>>>De : Qi Sun [mailto:sunqi.thu@gmail.c= om]
>>>Envoy=C3=A9 : lundi 15 avril 201= 3 17:47
>>>=C3=80 : BOUCADAIR Mohamed OLNC/OLN
>>>Cc : ian.farrer@telekom.de; Ted.Lemon@nomi= num.com; softwires@ietf.org;
>>>dhcwg@ietf.org
>>>Objet : Re: [dhcwg] [Softwires] = Adoption call on draft-scskf-dhc-dhcpv4-
>>>over-dhcpv6
>>>
>>>
>>>Dear Med,
>>>
>>>In MAP-E pure stateless mode, IP= v4 address (prefix) and port set are
>>>provisioned in MAP Rules as desi= gned. But in MAP-E 1:1 mode and lw4over= 6
>>>which are (kind of) stateful, it=  has to take into considerations about
>>>the
>>>lease time etc. issues. In this&= nbsp;case, IMHO, DHCPv4 over DHCPv6 is more<= /DIV>
>>>suitable for IPv4 related configurati= ons.
>>>
>>>What's more, DHCPv4-over-DHCPv6 is no= t only designed to deal with the
>>>option issues, but also to handl= e other architectural problems in
>>>transition (as Bernie mentioned in&nb= sp;previous mail). So I think
>>>DHCPv4-over-
>>>DHCPv6 is helpful for the evolve= ment in DHCP architecture.
>>>
>>>
>>>Best Regards,
>>>Qi Sun
>>>
>>>
>>>On 2013-4-15, at =E4=B8=8B=E5=8D=8811:13,&= nbsp;<mohamed.boucadair@orange.com>
>>><mohamed.boucadair@orange.com> wrote:
>>>
>>>> Hi Ian,
>>>>
>>>> Thanks for the clarification.
>>>> I understood from your answ= er: dhcpv6 will be used for both MAP&nb= sp;and
>>>lw4over6 and both don't require = draft-scskf-* for IP address + port
>>>provisioning.
>>>>
>>>> Given currently no additional&nb= sp;dhcpv4 only options is required for any
>>>>of
>>>the solutions we are discussing = in softwire, I do still think it is&nbs= p;not
>>>justified to take on a solution&= nbsp;for a problem which may not exist.
>>>>
>>>> draft-scskf-* proposal can be&nb= sp;revived when there is a real need to=
>>>support dhcpv4-only options. No?
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : ian.farrer@telekom.de [= mailto:ian.farrer@telekom.de]
>>>>> Envoy=C3=A9 : lundi 15 = avril 2013 16:56
>>>>> =C3=80 : BOUCADAIR Mohamed&n= bsp;OLNC/OLN; Ted.Lemon@nominum.com
>>>>> Cc : softwires@ietf.org; dhc= wg@ietf.org; sunqi.thu@gmail.com
>>>>> Objet : Re: [Softwires] = ;[dhcwg] Adoption call on
>>>>>draft-scskf-dhc-dhcpv4-
>>>>> over-dhcpv6
>>>>>
>>>>> Hi Med,
>>>>>
>>>>> It would still work for=  lw-4o6 and the unified CPE. All of&nbs= p;the basic
>>>>> params for configuring lw4o6= /MAP1:1 can be provisioned through the
>>>>> OPTION_MAP_BIND that is prop= osed in the unified CPE draft over DHCP= v6.
>>>>> Additional DHCPv4 only optio= ns would be done via the DHCPv4oDHCPv6
>>>method
>>>>> for both lw4o6 and MAP-= E.
>>>>>
>>>>> We still need to agree&= nbsp;on which option will be used for p= rovisioning
>>>>>the
>>>>> address of the lwAFTR/MAP&nb= sp;BR, however. There was some discussion on=
>>>>>this
>>>>> on the SW ML last = week, but no conclusion reached.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Ian
>>>>>
>>>>> On 15/04/2013 16:47, "mohame= d.boucadair@orange.com"
>>>>> <mohamed.boucadair@orange.com> w= rote:
>>>>>
>>>>>> Re-,
>>>>>>
>>>>>> Thanks for clarifying Te= d. I must admit this is not what I=  understood
>>>>>> when I read draft-scskf-= *.
>>>>>>
>>>>>> Does the same conclusion=  applies also for lw-4over6? (I'm naively
>>>>>> assuming, given the appr= oach defined in draft-ietf-softwire-unified-
>>>cpe,
>>>>>> the same dhcpv6 to = configure MAP will also be used lw-4over6)
>>>>>>
>>>>>> Cheers,
>>>>>> Med
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Ted Lemon = [mailto:Ted.Lemon@nominum.com]
>>>>>>> Envoy=C3=A9 : lundi = 15 avril 2013 16:39
>>>>>>> =C3=80 : BOUCADAIR M= ohamed OLNC/OLN
>>>>>>> Cc : Qi Sun; dh= cwg@ietf.org; Softwires (softwires@ietf.org)
>>>>>>> Objet : Re: [dhcwg]&= nbsp;Adoption call on draft-scskf-dhc-dhcpv4-over-
>>>dhcpv6
>>>>>>>
>>>>>>> On Apr 15, 2013,&nbs= p;at 10:27 AM, <mohamed.boucadair@orange.com> wr= ote:
>>>>>>>> Are you saying M= AP is not a concerned with this draft&n= bsp;and dhcpv6
>>>>>>>>can
>>>be
>>>>>>> used for MAP?
>>>>>>>
>>>>>>> For configuring the = MAP-E prefix and port set, yes.   = That was the
>>>>>>> discussion we had in=  Softwires in Orlando: cover the easy s= tuff with
>>>>>>> DHCPv6
>>>>>>> (this is the existin= g DHCPv6 MAP option), and then if someo= ne needs
>>>>>>> legacy
>>>>>>> IPv4 services or sta= teful address allocation, do it with
>>>>>>>DHCPv4-over-
>>>>>>> DHCPv6.
>>>>>>
>>>>>> _______________________________________= ________
>>>>>> Softwires mailing list
>>>>>> Softwires@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/s= oftwires
>>>>
>>>> _______________________________________________=
>>>> dhcwg mailing list
>>>> dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>_______________________________________________
>>Softwires mailing list
>>Softwires@ietf.org
>>https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart180462127502_=------ From Ted.Lemon@nominum.com Tue Apr 16 07:41:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0272821F9734; Tue, 16 Apr 2013 07:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKXt0ZpVyB7p; Tue, 16 Apr 2013 07:41:06 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED121F9731; Tue, 16 Apr 2013 07:41:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUW1jAaR1RrO/vxcnAVNzi4kh+5HdAm63@postini.com; Tue, 16 Apr 2013 07:41:06 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 713DD1B80F7; Tue, 16 Apr 2013 07:41:05 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 653DC190061; Tue, 16 Apr 2013 07:41:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 07:41:05 -0700 From: Ted Lemon To: Branimir Rajtar Thread-Topic: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOOfBwAFtz57uTokG2qMobiPMkY5jX4/iAgAA78YCAAC3VAIAABl8AgACY9YCAAHU+gA== Date: Tue, 16 Apr 2013 14:41:05 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514B67D@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36EC2D7C6EE@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E185070B8@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077514A222@mbx-01.win.nominum.com> <786F13AA11E69F4DB2CCA23F7400C2FB0142651D@S2010EXCH1.ad.local> In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0142651D@S2010EXCH1.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <39D94D6749C2F54A95EFFDC8C0E0EAD2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , Qi Sun , "Bernie Volz \(volz\)" , "Lee, Yiu" Subject: Re: [dhcwg] [Softwires] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:41:19 -0000 On Apr 16, 2013, at 3:41 AM, Branimir Rajtar wrot= e: > Just a short info on the the draft-rajtar work. Ian and I have been watch= ing closely the discussions here (with Ian taking the more active role) and= we're updating the draft accordingly. We hope to be able the publish the n= ew draft which will include dhcp4-over-dhcp6 and some other changes later t= his week and make a call for adoption. We feel that Ted's approach of "info= rmational-only" is the way to go. The new draft looks good. I did not have time to review all the pros and = cons, but I like the new table with evaluation criteria. BTW, I think thi= s draft should be BCP=97I was referring to the DHCPv4-over-IPv6 draft regar= ding informational status. Sorry for the confusion. From linux@thehobsons.co.uk Tue Apr 16 08:45:27 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB86421F9741 for ; Tue, 16 Apr 2013 08:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QoNYKtbjn0-s for ; Tue, 16 Apr 2013 08:45:27 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id DC84821F96B4 for ; Tue, 16 Apr 2013 08:45:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 45DEE29F98 for ; Tue, 16 Apr 2013 16:45:22 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7JWquxi9p6q for ; Tue, 16 Apr 2013 16:45:22 +0100 (BST) Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id C5C0629ECD for ; Tue, 16 Apr 2013 16:45:21 +0100 (BST) From: "Simon Hobson" To: dhcwg@ietf.org Date: Tue, 16 Apr 2013 16:45:24 +0100 X-Priority: 3 X-Mailer: MailForge 3.0 Mac OS X Message-ID: <054FA2F3C27EB55EA9DDDF42AD799FAC@thehobsons.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 15:45:27 -0000 Ted Lemon wrote: >> - Grouped subnets - this is where the giaddr or link-address are on a subnet/prefix that is not being used for address assignment and thus needs to be associated with another subnet/prefix. This is similar to the shared subnet, but no leases are being assigned from one of the subnets (the "source" subnet). > >Are there a lot of cases where this happens? I know there's a lot of goo in the protocol to support this behavior, but I haven't actually seen it used in the wild. Is this latter a special case of a shared subnet (ie where one subnet is nothing but a skeleton definition), or something else ? From Ted.Lemon@nominum.com Tue Apr 16 09:11:59 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBEF21F9774 for ; Tue, 16 Apr 2013 09:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIXzkS3gYtPf for ; Tue, 16 Apr 2013 09:11:58 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0D921F9772 for ; Tue, 16 Apr 2013 09:11:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUW14TLqVHUMvGb5NU/TSbi/GbbdmX/wo@postini.com; Tue, 16 Apr 2013 09:11: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 006681B80FA for ; Tue, 16 Apr 2013 09:11:56 -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 EA3D0190061; Tue, 16 Apr 2013 09:11:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 09:11:49 -0700 From: Ted Lemon To: Simon Hobson Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOrlo3k2MoTLQa0uUqsbeRb1B3pjZehcA Date: Tue, 16 Apr 2013 16:11:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514B959@mbx-01.win.nominum.com> References: <054FA2F3C27EB55EA9DDDF42AD799FAC@thehobsons.co.uk> In-Reply-To: <054FA2F3C27EB55EA9DDDF42AD799FAC@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D468923F36F84418ED0662221B23701@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 16:12:00 -0000 On Apr 16, 2013, at 11:45 AM, Simon Hobson wrote: > Is this latter a special case of a shared subnet (ie where one subnet is = nothing but a skeleton definition), or something else ? Again, I don't really know. The link selection suboption and the subnet s= election option in DHCPv4 are examples of this. And then there are cases = in provider environments where you might have a PE router connected to a bu= nch of links that you're treating as a single link, but you want to control= the address allocation based on a link identifier (e.g., Circuit ID), for = example. From volz@cisco.com Tue Apr 16 21:12:08 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F1321F97D6 for ; Tue, 16 Apr 2013 21:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkxQE5uTXERk for ; Tue, 16 Apr 2013 21:12:07 -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 081AF21F97D3 for ; Tue, 16 Apr 2013 21:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1514; q=dns/txt; s=iport; t=1366171927; x=1367381527; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=B3CGeW8AwHbtRTI7npRpyDdQwIisy+CKV73iWTH1WCc=; b=PW0a/nf1Iz7hDvmg5YLC49Xs5YINl54wsHZBHwj5x/2MALWi6rZ15D8I k+P22NHUWpcL7AvnHXLDOAbMwEMw3/w3Nr1cToXfagLjZZ43OdNpWyPjd GK+T429gHZz/TUa9nX7qr/hpN//n8AeoI3XnqpVwQTeB9PoS7AB4W6FSN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKQfblGtJXG8/2dsb2JhbABQgwY2wQqBDhZ0gh8BAQEEAQEBNzQXBAIBCA4DBAEBAQoUCQcnCxQJCAIEARIIiAwMvQAEjmomEgaCXmEDqBqDC4Io X-IronPort-AV: E=Sophos;i="4.87,489,1363132800"; d="scan'208";a="199413683" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 17 Apr 2013 04:12:06 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3H4C6FV019531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 04:12:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 23:12:05 -0500 From: "Bernie Volz (volz)" To: Simon Hobson , "dhcwg@ietf.org" Thread-Topic: [dhcwg] draft-lemon-dhc-topo-conf Thread-Index: AQHOOrlo3k2MoTLQa0uUqsbeRb1B3pjZzPOg Date: Wed, 17 Apr 2013 04:12:05 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850AA40@xmb-rcd-x04.cisco.com> References: <054FA2F3C27EB55EA9DDDF42AD799FAC@thehobsons.co.uk> In-Reply-To: <054FA2F3C27EB55EA9DDDF42AD799FAC@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf 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 Apr 2013 04:12:08 -0000 That is indeed one way you can think about it. A v4 example is that giaddr is 10.1.0.1 and you want to allocate leases fro= m 10.2.*.*. So you might set up a subnet for 10.1.0.0/24 and 10.2.0.0/16. N= o leases are configured for the 10.1.0.0/24. There may be other considerations for the 10.1.0.0/24 - such as not do supp= ort INFORMs from that subnet; but that's a more minor detail and rarely tha= t significant since probably there are no 'real' DHCP clients on it anyway. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S= imon Hobson Sent: Tuesday, April 16, 2013 11:45 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] draft-lemon-dhc-topo-conf Ted Lemon wrote: >> - Grouped subnets - this is where the giaddr or link-address are on a su= bnet/prefix that is not being used for address assignment and thus needs to= be associated with another subnet/prefix. This is similar to the shared su= bnet, but no leases are being assigned from one of the subnets (the "source= " subnet). > >Are there a lot of cases where this happens? I know there's a lot of goo= in the protocol to support this behavior, but I haven't actually seen it u= sed in the wild. Is this latter a special case of a shared subnet (ie where one subnet is no= thing but a skeleton definition), or something else ? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From bingxuere@gmail.com Wed Apr 17 01:51:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E1C21F8AD1 for ; Wed, 17 Apr 2013 01:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Zgo9rCqzyq for ; Wed, 17 Apr 2013 01:50:59 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4867521F8A8A for ; Wed, 17 Apr 2013 01:50:59 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x13so1085785vbb.34 for ; Wed, 17 Apr 2013 01:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jXL2tFTBcnW5b6jmLQNC4qvP47aqgDcUMHPPrpG1VuY=; b=UiPwF24umAjgJHDPphcqfNx03gO+5FS0ialmq+iJTUvAmE4wVFAOeenNYnwXb/YxGT QUGwnmxCGf0n9qUy1riTxyu4cvdzmRoS1niBLjj3m1Vm0SXSCYPG3m4xm3pWGsE9x61g YvZVM3mvd7uvIlP6z4Sm117Iz51jMhn55e8j0juasBi7gwIRrD6cLAYoGrDKt4iSbfQf a4NZqMGGOZHerwMoVNeSUDf8oGlUIjNRh7eN4dN2C2Jw/oiLAeUq9LGgvIeDXdcmai/O 8JWXOoyUAfA1Iwf424EEMkKuoUE05rE6SEY1B3Yb/xP5ky+qNxQevcap8//NlecdgF/F xe4w== X-Received: by 10.52.28.196 with SMTP id d4mr3525643vdh.56.1366188658751; Wed, 17 Apr 2013 01:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.224.133 with HTTP; Wed, 17 Apr 2013 01:50:17 -0700 (PDT) In-Reply-To: <515C69A4.7000903@gmail.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> From: Qiong Date: Wed, 17 Apr 2013 16:50:17 +0800 Message-ID: To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=20cf3079bc02b3ac0904da8a9580 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 08:51:04 -0000 --20cf3079bc02b3ac0904da8a9580 Content-Type: text/plain; charset=UTF-8 +1 support. I think this work is quite useful. Best wishes Qiong On Thu, Apr 4, 2013 at 1:40 AM, Tomek Mrugalski wrote: > Hi all, > > This draft is a result of the discussion we had during last meeting in > Orlando. We have very productive discussion about IPv4 hosts > configuration in IPv6-only network. After we reached what looked like a > consensus in the meeting room, couple folks volunteered to write down > the draft that summarizes that perceived consensus. This draft is a > product of this effort. > > As requested by authors, we are announcing adotion call on > draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to > confirm whether there is WG consensus to adopt this work as DHC WG > draft. Please state whether or not you're in favor of the adoption by > replying to this mail. If you are not in favor, please also state your > objections in your response. This adoption call will complete on > 2013-04-17. > > Regards, > Bernie & Tomek > > On 03.04.2013 19:20, Marcin Siodelski wrote: > > In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am asking > > for adoption of this document by DHC WG. > > > > The latest version (-01) is available here: > > > > > http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over-dhcpv6-01.txt > > http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-over-dhcpv6-01 > > > > This document describes a mechanism whereby IPv4 client obtains its > > configuration from the DHCPv4 server separated from the client by IPv6- > > only network having DHCPv6 service. This mechanism is frequently > > referred as "DHCPv4-over-DHCPv6". > > > > The DHCPv4 client's request is carried in the newly defined DHCPv6 > > messages/option to/from the server and can be sent either through a > > relay or directly. > > > > Cheers, > > Marcin > > > > > > > > _______________________________________________ > > 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 > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --20cf3079bc02b3ac0904da8a9580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 support. I think this work is quite useful.=C2=A0
=C2=A0
Best wishes
Qiong=C2=A0

On Thu, Apr 4, 2013 at 1:40 AM, Tomek Mrugalski = <tomasz.mrugalski@gmail.com> wrote:
Hi all,

This draft is a result= of the discussion we had during last meeting in
Orlando. We have very p= roductive discussion about IPv4 hosts
configuration in IPv6-only network. After we reached what looked like a
= consensus in the meeting room, couple folks volunteered to write down
th= e draft that summarizes that perceived consensus. This draft is a
produc= t of this effort.

As requested by authors, we are announcing adotion call on
draft-scs= kf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to
confirm wh= ether there is WG consensus to adopt this work as DHC WG
draft. Please s= tate whether or not you're in favor of the adoption by
replying to this mail. If you are not in favor, please also state your
o= bjections in your response. This adoption call will complete on 2013-04-17.=

Regards,
Bernie & Tomek

On 03.04.2013 19:20, Marcin S= iodelski wrote:
> In the name of authors of draft-scskf-dhc-dhcpv4-over-dhcpv6 I am aski= ng
> for adoption of this document by DHC WG.
>
> The lat= est version (-01) is available here:
>
> http://www.ietf.org/internet-drafts/draft-scskf-dhc-dhcpv4-over= -dhcpv6-01.txt
> http://tools.ietf.org/html/draft-scskf-dhc-dhcpv4-= over-dhcpv6-01
>
> This document describes a mechanism wher= eby IPv4 client obtains its
> configuration from the DHCPv4 server separated from the client by IPv6= -
> only network having DHCPv6 service. This mechanism is frequently<= br>> referred as "DHCPv4-over-DHCPv6".
>
> The DHC= Pv4 client's request is carried in the newly defined DHCPv6
> messages/option to/from the server and can be sent either through a> relay or directly.
>
> Cheers,
> Marcin
>
= >
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@iet= f.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/m= ailman/listinfo/dhcwg



--
=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=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D
--20cf3079bc02b3ac0904da8a9580-- From bingxuere@gmail.com Wed Apr 17 01:56:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B7421F8B0A for ; Wed, 17 Apr 2013 01:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3nca3r66i-W for ; Wed, 17 Apr 2013 01:55:56 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id AFAF221F8A4E for ; Wed, 17 Apr 2013 01:55:56 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id w8so1064927vbf.25 for ; Wed, 17 Apr 2013 01:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sFEY8eZeiL0GcN/H9y+VMLtvY+P/kJG/mF4JRBaBDps=; b=jHsumt6wNpSQq+5kRkfOBceEkJGJQ/aGdcjfK3Ow2fCwoRNxFkDQ78PGZahFAkoXe7 TPgUOQd7qZ9Cfb4iap+1g+V1/eF8CnKYIwk5W1NDAE6+457/bQ2YCq2IxYSRJLIU8zk6 rgEQ5jZT9+Aiy5U6zIDOQf1IlDXVwlcdWLDru7bzoSLaqiy9gZaCbN/h06V6XdRAZR5v tqRN+8ngu1k17+Ku7FuJiOa2V9Q03CxduDGbvtmVeFaC/rUlOkt6zINJAnlB7y685YEH +e2I5bX3g9Rr87RjDm19Z8OZOlyIvDa0/W6NuJ0PqcBIdaHfNL3HrEr0u0frnol7wYXZ V5fA== X-Received: by 10.58.212.8 with SMTP id ng8mr4166605vec.25.1366188956198; Wed, 17 Apr 2013 01:55:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.224.133 with HTTP; Wed, 17 Apr 2013 01:55:16 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AA19456@nkgeml512-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> <5162F5DB.7010404@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AA19456@nkgeml512-mbx.china.huawei.com> From: Qiong Date: Wed, 17 Apr 2013 16:55:16 +0800 Message-ID: To: Sheng Jiang Content-Type: multipart/alternative; boundary=047d7bd6af506e6e7f04da8aa7f7 Cc: dhcwg Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 08:56:01 -0000 --047d7bd6af506e6e7f04da8aa7f7 Content-Type: text/plain; charset=UTF-8 Hi all, I'm in favor of adoption this work. Best wishes Qiong On Mon, Apr 15, 2013 at 5:45 PM, Sheng Jiang wrote: > I do support the adoption of this draft. Useful work. However, I do think > this draft should go further to include both unknown message and unknown > OPTIONS. > > Best regards, > > Sheng > > >-----Original Message----- > >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > >Of Tomek Mrugalski > >Sent: Tuesday, April 09, 2013 12:53 AM > >To: dhcwg > >Subject: Re: [dhcwg] Adoption call on > >draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 > > > >On 03.04.2013 20:04, Bernie Volz (volz) wrote: > >> While I think it is appropriate for the WG to adopt this document, I do > have > >comments on the draft itself. > >This is a small, but important draft. By clarifying that relays must > >forward unknown messages it provides forward compatibility with any > >future extensions that define new message types. We know that there's > >one around the corner already, but there may be more ahead. > > > >It is very useful. I do support adoption of this draft. This is > >definitely something DHC WG should work on. Fortunately, there's not > >much work left to be done. > > > >Minor comment: I would add in section 3.2 "regardless of the message > >type in Relay Message option". > > > >Tomek > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --047d7bd6af506e6e7f04da8aa7f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
=C2=A0
I'm in favor of adoption this work.
=C2=A0
Best wishes
Qiong=C2=A0=C2=A0
=C2=A0
=C2=A0
On Mon, Apr 15, 2013 at 5:45 PM, Sheng Jiang <jiangsheng@huawei.c= om> wrote:
I do support the adoption of this dra= ft. Useful work. However, I do think this draft should go further to includ= e both unknown message and unknown OPTIONS.

Best regards,

Sheng

>-----Original Message-----
>From: dhcwg-bounces@ietf.org [mailto:= dhcwg-bounces@ietf.org] On Be= half
>Of Tomek Mrugalski
>Sent: Tuesday, April 09, 2013 12:53 AM
>= To: dhcwg
>Subject: Re: [dhcwg] Adoption call on
>draft-csl-dhc= -dhcpv6-unknown-msg-3315update-00
>
>On 03.04.2013 20:04, Bernie Volz (volz) wrote:
>= ;> While I think it is appropriate for the WG to adopt this document, I = do have
>comments on the draft itself.
>This is a small, but im= portant draft. By clarifying that relays must
>forward unknown messages it provides forward compatibility with any
= >future extensions that define new message types. We know that there'= ;s
>one around the corner already, but there may be more ahead.
>
>It is very useful. I do support adoption of this draft. This is=
>definitely something DHC WG should work on. Fortunately, there'= s not
>much work left to be done.
>
>Minor comment: I wou= ld add in section 3.2 "regardless of the message
>type in Relay Message option".
>
>Tomek
>
>= ;_______________________________________________
>dhcwg mailing list<= br>>dhcwg@ietf.org
>https://= www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/m= ailman/listinfo/dhcwg



--
=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=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D
--047d7bd6af506e6e7f04da8aa7f7-- From Branimir.Rajtar@t.ht.hr Wed Apr 17 02:07:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC9C21F863B for ; Wed, 17 Apr 2013 02:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkCHrpLkx34R for ; Wed, 17 Apr 2013 02:07:52 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id 1F17921F8B3A for ; Wed, 17 Apr 2013 02:07:43 -0700 (PDT) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Wed, 17 Apr 2013 10:35:36 +0200 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 1b00_5d52_402436be_a73e_11e2_b86a_00219b931f47; Wed, 17 Apr 2013 11:07:37 +0200 Received: (private information removed) Wed, 17 Apr 2013 11:07:38 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Wed, 17 Apr 2013 11:07:37 +0200 From: Branimir Rajtar To: Qiong , Tomek Mrugalski Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOO0i7Dt6gt01A0UuOjlsm4We62JjaH1Sw Date: Wed, 17 Apr 2013 09:07:37 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01426A13@S2010EXCH1.ad.local> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB01426A13S2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2013 09:07:38.0145 (UTC) FILETIME=[01F08910:01CE3B4B] Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 09:07:57 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB01426A13S2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 KzEgYXMgd2VsbA0KDQpCUiwNCkJyYW5pbWlyDQoNCkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWlvbmcNClNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMTcsIDIwMTMgMTA6NTAgQU0NClRvOiBUb21layBNcnVnYWxz a2kNCkNjOiBkaGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaGN3Z10gQWRvcHRpb24gY2Fs bCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2DQoNCisxIHN1cHBvcnQuIEkg dGhpbmsgdGhpcyB3b3JrIGlzIHF1aXRlIHVzZWZ1bC4NCg0KQmVzdCB3aXNoZXMNClFpb25nDQpP biBUaHUsIEFwciA0LCAyMDEzIGF0IDE6NDAgQU0sIFRvbWVrIE1ydWdhbHNraSA8dG9tYXN6Lm1y dWdhbHNraUBnbWFpbC5jb208bWFpbHRvOnRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tPj4gd3Jv dGU6DQpIaSBhbGwsDQoNClRoaXMgZHJhZnQgaXMgYSByZXN1bHQgb2YgdGhlIGRpc2N1c3Npb24g d2UgaGFkIGR1cmluZyBsYXN0IG1lZXRpbmcgaW4NCk9ybGFuZG8uIFdlIGhhdmUgdmVyeSBwcm9k dWN0aXZlIGRpc2N1c3Npb24gYWJvdXQgSVB2NCBob3N0cw0KY29uZmlndXJhdGlvbiBpbiBJUHY2 LW9ubHkgbmV0d29yay4gQWZ0ZXIgd2UgcmVhY2hlZCB3aGF0IGxvb2tlZCBsaWtlIGENCmNvbnNl bnN1cyBpbiB0aGUgbWVldGluZyByb29tLCBjb3VwbGUgZm9sa3Mgdm9sdW50ZWVyZWQgdG8gd3Jp dGUgZG93bg0KdGhlIGRyYWZ0IHRoYXQgc3VtbWFyaXplcyB0aGF0IHBlcmNlaXZlZCBjb25zZW5z dXMuIFRoaXMgZHJhZnQgaXMgYQ0KcHJvZHVjdCBvZiB0aGlzIGVmZm9ydC4NCg0KQXMgcmVxdWVz dGVkIGJ5IGF1dGhvcnMsIHdlIGFyZSBhbm5vdW5jaW5nIGFkb3Rpb24gY2FsbCBvbg0KZHJhZnQt c2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMS4gVGhpcyBjYWxsIGlzIGJlaW5nIGluaXRp YXRlZCB0bw0KY29uZmlybSB3aGV0aGVyIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyB0byBhZG9wdCB0 aGlzIHdvcmsgYXMgREhDIFdHDQpkcmFmdC4gUGxlYXNlIHN0YXRlIHdoZXRoZXIgb3Igbm90IHlv dSdyZSBpbiBmYXZvciBvZiB0aGUgYWRvcHRpb24gYnkNCnJlcGx5aW5nIHRvIHRoaXMgbWFpbC4g SWYgeW91IGFyZSBub3QgaW4gZmF2b3IsIHBsZWFzZSBhbHNvIHN0YXRlIHlvdXINCm9iamVjdGlv bnMgaW4geW91ciByZXNwb25zZS4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29tcGxldGUgb24g MjAxMy0wNC0xNy4NCg0KUmVnYXJkcywNCkJlcm5pZSAmIFRvbWVrDQoNCk9uIDAzLjA0LjIwMTMg MTk6MjAsIE1hcmNpbiBTaW9kZWxza2kgd3JvdGU6DQo+IEluIHRoZSBuYW1lIG9mIGF1dGhvcnMg b2YgZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NiBJIGFtIGFza2luZw0KPiBmb3Ig YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBieSBESEMgV0cuDQo+DQo+IFRoZSBsYXRlc3QgdmVy c2lvbiAoLTAxKSBpcyBhdmFpbGFibGUgaGVyZToNCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMS50eHQN Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVy LWRoY3B2Ni0wMQ0KPg0KPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB3aGVy ZWJ5IElQdjQgY2xpZW50IG9idGFpbnMgaXRzDQo+IGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgREhD UHY0IHNlcnZlciBzZXBhcmF0ZWQgZnJvbSB0aGUgY2xpZW50IGJ5IElQdjYtDQo+IG9ubHkgbmV0 d29yayBoYXZpbmcgREhDUHY2IHNlcnZpY2UuIFRoaXMgbWVjaGFuaXNtIGlzIGZyZXF1ZW50bHkN Cj4gcmVmZXJyZWQgYXMgIkRIQ1B2NC1vdmVyLURIQ1B2NiIuDQo+DQo+IFRoZSBESENQdjQgY2xp ZW50J3MgcmVxdWVzdCBpcyBjYXJyaWVkIGluIHRoZSBuZXdseSBkZWZpbmVkIERIQ1B2Ng0KPiBt ZXNzYWdlcy9vcHRpb24gdG8vZnJvbSB0aGUgc2VydmVyIGFuZCBjYW4gYmUgc2VudCBlaXRoZXIg dGhyb3VnaCBhDQo+IHJlbGF5IG9yIGRpcmVjdGx5Lg0KPg0KPiBDaGVlcnMsDQo+IE1hcmNpbg0K Pg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3 ZyBtYWlsaW5nIGxpc3QNCmRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0KDQoNCi0tDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpRaW9uZyBTdW4NCkNo aW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1ZGUNCg0KDQpPcGVuIHNvdXJjZSBj b2RlOg0KbGlnaHR3ZWlnaHQgNG92ZXI2OiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3Rz L2xhZnQ2Lw0KUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3Bj cHBvcnRzZXRkZW1vLw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCgoKPEhUTUw+PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4N Cg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVrZSBp IGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5q ZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJl c2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZhcywg b2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtl IG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmlsbyBr YWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEg c2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vxb5l IGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVuamEg aXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBz dGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHE h2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHByaW1p dGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+ PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJ TUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFj aGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZp ZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNo ZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRp c3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVj ZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVs ZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3Ig YW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0 YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+PC9IVE1MPgo= --_000_786F13AA11E69F4DB2CCA23F7400C2FB01426A13S2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczpiPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpwdWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6Yz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxuczpv ZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9kYyIgeG1sbnM6b2E9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6 Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5zOnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNv YXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9Imh0dHA6Ly9taWNyb3NvZnQuY29tL29m ZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRBVjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5zOm10PSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5ncy8iIHhtbG5zOngyPSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0 cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzPSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5z OmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQu Y29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRzLyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cu dzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1M U2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3Zj0iaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzPSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWciIHhtbG5zOm1k c3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0 YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5v cmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptcmVscz0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlvbnNoaXBzIiB4bWxuczpz cHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6 ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAw Ni90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFu Z2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRlTGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0 dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1NoYXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVi bGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIg eG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4N CjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0 bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBE ZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkhSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+JiM0MzsxIGFzIHdlbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CcmFuaW1pcjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZGhjd2ctYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlFpb25nPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTcsIDIwMTMg MTA6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvbWVrIE1ydWdhbHNraTxicj4NCjxiPkNjOjwvYj4g ZGhjd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaGN3Z10gQWRvcHRpb24g Y2FsbCBvbiBkcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgc3VwcG9ydC4gSSB0aGluayB0 aGlzIHdvcmsgaXMgcXVpdGUgdXNlZnVsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHdpc2hlczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5RaW9uZyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgNCwgMjAxMyBhdCAxOjQwIEFNLCBUb21layBNcnVn YWxza2kgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21hc3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPGJyPg0KPGJyPg0KVGhp cyBkcmFmdCBpcyBhIHJlc3VsdCBvZiB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgZHVyaW5nIGxhc3Qg bWVldGluZyBpbjxicj4NCk9ybGFuZG8uIFdlIGhhdmUgdmVyeSBwcm9kdWN0aXZlIGRpc2N1c3Np b24gYWJvdXQgSVB2NCBob3N0czxicj4NCmNvbmZpZ3VyYXRpb24gaW4gSVB2Ni1vbmx5IG5ldHdv cmsuIEFmdGVyIHdlIHJlYWNoZWQgd2hhdCBsb29rZWQgbGlrZSBhPGJyPg0KY29uc2Vuc3VzIGlu IHRoZSBtZWV0aW5nIHJvb20sIGNvdXBsZSBmb2xrcyB2b2x1bnRlZXJlZCB0byB3cml0ZSBkb3du PGJyPg0KdGhlIGRyYWZ0IHRoYXQgc3VtbWFyaXplcyB0aGF0IHBlcmNlaXZlZCBjb25zZW5zdXMu IFRoaXMgZHJhZnQgaXMgYTxicj4NCnByb2R1Y3Qgb2YgdGhpcyBlZmZvcnQuPGJyPg0KPGJyPg0K QXMgcmVxdWVzdGVkIGJ5IGF1dGhvcnMsIHdlIGFyZSBhbm5vdW5jaW5nIGFkb3Rpb24gY2FsbCBv bjxicj4NCmRyYWZ0LXNjc2tmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYtMDEuIFRoaXMgY2FsbCBp cyBiZWluZyBpbml0aWF0ZWQgdG88YnI+DQpjb25maXJtIHdoZXRoZXIgdGhlcmUgaXMgV0cgY29u c2Vuc3VzIHRvIGFkb3B0IHRoaXMgd29yayBhcyBESEMgV0c8YnI+DQpkcmFmdC4gUGxlYXNlIHN0 YXRlIHdoZXRoZXIgb3Igbm90IHlvdSdyZSBpbiBmYXZvciBvZiB0aGUgYWRvcHRpb24gYnk8YnI+ DQpyZXBseWluZyB0byB0aGlzIG1haWwuIElmIHlvdSBhcmUgbm90IGluIGZhdm9yLCBwbGVhc2Ug YWxzbyBzdGF0ZSB5b3VyPGJyPg0Kb2JqZWN0aW9ucyBpbiB5b3VyIHJlc3BvbnNlLiBUaGlzIGFk b3B0aW9uIGNhbGwgd2lsbCBjb21wbGV0ZSBvbiAyMDEzLTA0LTE3Ljxicj4NCjxicj4NClJlZ2Fy ZHMsPGJyPg0KQmVybmllICZhbXA7IFRvbWVrPGJyPg0KPGJyPg0KT24gMDMuMDQuMjAxMyAxOToy MCwgTWFyY2luIFNpb2RlbHNraSB3cm90ZTo8YnI+DQomZ3Q7IEluIHRoZSBuYW1lIG9mIGF1dGhv cnMgb2YgZHJhZnQtc2Nza2YtZGhjLWRoY3B2NC1vdmVyLWRoY3B2NiBJIGFtIGFza2luZzxicj4N CiZndDsgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYnkgREhDIFdHLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoZSBsYXRlc3QgdmVyc2lvbiAoLTAxKSBpcyBhdmFpbGFibGUgaGVyZTo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nza2Yt ZGhjLWRoY3B2NC1vdmVyLWRoY3B2Ni0wMS50eHQ8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2 LTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z Y3NrZi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2LTAxPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIHdoZXJlYnkgSVB2NCBjbGllbnQgb2J0 YWlucyBpdHM8YnI+DQomZ3Q7IGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgREhDUHY0IHNlcnZlciBz ZXBhcmF0ZWQgZnJvbSB0aGUgY2xpZW50IGJ5IElQdjYtPGJyPg0KJmd0OyBvbmx5IG5ldHdvcmsg aGF2aW5nIERIQ1B2NiBzZXJ2aWNlLiBUaGlzIG1lY2hhbmlzbSBpcyBmcmVxdWVudGx5PGJyPg0K Jmd0OyByZWZlcnJlZCBhcyAmcXVvdDtESENQdjQtb3Zlci1ESENQdjYmcXVvdDsuPGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhlIERIQ1B2NCBjbGllbnQncyByZXF1ZXN0IGlzIGNhcnJpZWQgaW4gdGhl IG5ld2x5IGRlZmluZWQgREhDUHY2PGJyPg0KJmd0OyBtZXNzYWdlcy9vcHRpb24gdG8vZnJvbSB0 aGUgc2VydmVyIGFuZCBjYW4gYmUgc2VudCBlaXRoZXIgdGhyb3VnaCBhPGJyPg0KJmd0OyByZWxh eSBvciBkaXJlY3RseS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBNYXJj aW48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBkaGN3ZyBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RoY3dnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaGN3ZzwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhj d2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RoY3dnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4N Ci0tIDxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+DQpRaW9uZyBTdW48YnI+DQpDaGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0 dWRlPGJyPg0KPGJyPg0KPGJyPg0KT3BlbiBzb3VyY2UgY29kZTo8YnI+DQpsaWdodHdlaWdodCA0 b3ZlcjY6IDxpPjxhIGhyZWY9Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni88 L2E+PC9pPjxicj4NClBDUC1uYXRjb29yZDo8aT4gPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdl Lm5ldC9wcm9qZWN0cy9wY3Bwb3J0c2V0ZGVtby8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9z b3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNwcG9ydHNldGRlbW8vPC9hPiA8L2k+PGJyPg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KCjxESVY+PFA+PEhSPgo8UD48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSBm YWNlPUFyaWFsPklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHImIzM4MjthaiBv dmUgcG9ydWtlIGkgZXZlbnR1YWxubyBwcmlsbyYjMzgyO2VuaWggZGF0b3Rla2EgamUgcG92amVy bGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3Ug bmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmUmIzM1 Mztrb20sIG1vbGltbyBWYXMsIG9iYXZpamVzdGl0ZSBwbyYjMzUzO2lsamF0ZWxqYSwgYSBwb3J1 a3UgaSBzdmUgbmplbmUgcHJpdml0a2Ugb2RtYWgsIGJleiAmIzI2OTtpdGFuamEsIHRyYWpubyB1 a2xvbml0ZSBzIHJhJiMyNjk7dW5hbGEuIEJpbG8ga2Frdm8gcHJlbm8mIzM1MztlbmplLCBrb3Bp cmFuamUgaWxpIGRpc3RyaWJ1Y2lqYSBpbmZvcm1hY2lqYSBzYWRyJiMzODI7YW5paCB1IHBvcnVj aSB0cmUmIzI2MztpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtbyYjMzgyO2UgYml0aSB6YWtv bnNraSBrYSYjMzgyO25qaXZvLiBTYWRyJiMzODI7YWosIHN0YXZvdmkgaSBtaSYjMzUzO2xqZW5q YSBpem5lc2VuaSB1IHBvcnVjaSBzdSBhdXRvcm92aSBpIG5lIHByZWRzdGF2bGphanUgbnUmIzM4 MjtubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza29nIFRlbGVrb21hIGQuZC4gSFQgbmUgcHJpaHZhJiMy NjM7YSBuaWtha3Z1IG9kZ292b3Jub3N0IHphIGV2ZW50dWFsbnUgJiMzNTM7dGV0dSBuYXN0YWx1 IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyJiMzODI7YW5paCB1IHBvcnVjaS4g PC9GT05UPjwvUD4NCjxQPjxGT05UIGNvbG9yPSM5OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+RElT Q0xBSU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBh dHRhY2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGlu ZGl2aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0 dGFjaGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBv ciBkaXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQg aGVyZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQg aW4gdGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90 IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFu IFRlbGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkg Zm9yIGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVz IGF0dGFjaGVkIHRvIGl0LiA8L0ZPTlQ+PC9QPgo8L1A+PC9ESVY+CjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_786F13AA11E69F4DB2CCA23F7400C2FB01426A13S2010EXCH1adloc_-- From leaf.yeh.sdo@gmail.com Wed Apr 17 04:07:10 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40721F8D2E for ; Wed, 17 Apr 2013 04:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.371 X-Spam-Level: *** X-Spam-Status: No, score=3.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 8ZsJllqaauta for ; Wed, 17 Apr 2013 04:07:09 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2425021F8D29 for ; Wed, 17 Apr 2013 04:07:09 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id s35so735562dak.6 for ; Wed, 17 Apr 2013 04:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=yGDc3jgiDy9jzVsGdrEiKvnR8uWI1vYN8leP4AdX7AY=; b=KIqn+yp7slOuAn88IsVYt7kUU4F1zRFHZdqSKRoR4G+VXoUm0RVkef+LghMZMfdi+6 Al6f6i9YfNi7NpGdIXRlswMlLg+K+2MbeF2h8inDIRiS1t3wcB18/R9qwhNhFKIjXDI1 jjKbaQ81nKEZEU0ymdy4yH/ACvaEdiGOhCNkLdR/VWU7dDaK+Hj28v2ZdcMvML9jivbh GzDvLCrIp+tJD4/sO8HmxiLaqRHv26tmI5cPXBDildomwM2zVWOQ0MyUw6DZR69ZYGk1 3xyiD2xq5a80cyb6ZJ5hb1mj3B0d7q7/NPIsRav14rSaqnZZ3oIXQ8qjEsK2P+L6hF15 5kvw== X-Received: by 10.68.236.134 with SMTP id uu6mr8650863pbc.55.1366196828891; Wed, 17 Apr 2013 04:07:08 -0700 (PDT) Received: from PC ([61.48.185.127]) by mx.google.com with ESMTPS id ba10sm5946335pbd.21.2013.04.17.04.07.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Apr 2013 04:07:07 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com> In-Reply-To: <516AA05E.3070801@gmail.com> Date: Wed, 17 Apr 2013 19:07:00 +0800 Message-ID: <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac45Cz/py3/bdmb7QvCqM9bmbO85vQBX/aqA Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:07:10 -0000 Tomek - How about "Misconfigured or compromised DHCPv6 server can cause relays to start announcing arbitrary prefixes, including default routes, which could lead to traffic hijack."? I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't bought in the part of 'Compromised DHCPv6 server'. I don't believe the ORO option included by the relay could compromise the DHCPv6 server. Right? > Tomek - ...this draft repeats normative language from RFC3315 (e.g. > "The relay agent SHOULD include the Interface ID option")... Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: "The server MAY use the link-address specified in RELAY-FORW message to identify the relay agent itself or its particular customer-facing interface where the prefix pool is associated, but the server has to maintain the binding data of prefix pools in association with these link-addresses. To be more readable, the server can alternatively use the Interface ID option included in the RELAY-FORW message by the relay agent to identify the relay agent itself or its particular customer-facing interface where the prefix pool is associated. In order to give a meaningful reply, the server has to maintain the binding data of prefix pools in association with the information derived from the Interface ID option." The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both use cases shown in section 3. Tomek -RFC3315: relay MUST include interface-id if the link-address in server's response is not sufficient to select downlink interface. prefix-pool-opt-02: relay SHOULD include interface-id, so the the server can identify the relay itself (tomek: that's wrong. Interface-id is for interface or subnet identification, not relay identification. Relay-id is used for that purpose, see RFC5460, section 5.4.1) There might be a small debate here. The question could be whether the server could identify the relay after receiving the interface-id of it. I guess our smart server already support that in the real deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be able to use Option 18 in order to retrieve the Access Node identifier and access this table in order to identify the ad-hoc pool of prefixes or addresses.] OTOH, I believe relay-id defined in RFC5460 can also be used in the case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. 2); though if the mechanism of Bulk-Lease-Query is employed, the relay also need to include OPTION_ RELAY_ID in the relay-forward message for the basic operation of DHCPv6 prefix or address assignment. Tomek - ... if the server would not like to use the link-address field specified in RELAY-FORW message (tomek: that imprecise or wrong. The server is not at liberty to "not use link-address field". There's a specific algorithm defined in section 11 of RFC3315 that the server must follow it). Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, has the following text: " A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from some combination of the following sources: - The link to which the client is attached. ... If the server receives the message from a forwarding relay agent, then the client is on the same link as the one to which the interface, identified by the link-address field in the message from the relay agent, is attached... - The DUID supplied by the client. - Other information in options supplied by the client. - Other information in options supplied by the relay agent." The above text sounds not put link-address ahead of options supplied by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF TR-177, its R-07, R-08 & section6.6 (...In some deployments there is neither a need nor a desire to configure a global or unique local address to the interface on which the client messages are received. Such a deployment does not allow the BNG to insert an IPv6 address in the link-address field...).] Best Regards, Leaf -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] Sent: Sunday, April 14, 2013 8:26 PM To: Leaf Yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 On 13-04-12 03:15, Leaf Yeh wrote: > Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? > Your relay will hijack the whole network? ... > > The relay's behavior is still under control by the server. If it got > the wrong configuration, the server could also send out ::/0 in the > IA_PD. So this may sound an administration error. We just want the > prefix pools not configure to be ::/0 or any overlap between them. I > feel a little stuck on the exact text you want. How about 'The > administrator of the DHCPv6 server should pay more attention to the > configuration of the prefix pools, for examples, a. ::/0 may cause a > big routing problem in the whole ISP network; b. the configuration of > prefix pool should avoid overlap in the address plan, and etc.' ? I am not quite sure... Administrator mistake is one concern, the other one is that DHCPv6 server may become an attractive attack target when prefix-pool is deployed. How about "Misconfigured or compromised DHCPv6 server can cause relays to start announcing arbitrary prefixes, including default routes, which could lead to traffic hijack."? > Tomek - Bernie had this concern and I tend to agree with him... the > length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my > reply to Bernie's email. Thanks for your suggestion here. Do we need > more explanation on the mathematic function of floor() ? :-) I don't think so. A potential implementor who doesn't know what floor() function does should probably consider starting a career in some other industry. :-) > Tomek - ...(I know that requestor in most cases is part of a relay, > but from protocol perspective these are separate entities)...Yes. > Please split actions taken by requestor into separate section. It can > be subsection 5.1 if you like to. > > Do you mean add section 5.1 "Leasequery Requestor Behavior" in the > section 5 "Relay Agent Behavior" (just for an editorial change)? Do > you want section > 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? Yes to both. > Tomek - ...this draft repeats normative language from RFC3315 (e.g. > "The relay agent SHOULD include the Interface ID option")... > > After searching and reading, I still can't find this sentence in RFC3315. It is in prefix-pool-opt-02, section 5, second paragraph. Text from prefix-pool-opt-02 is an imprecise subset of behaviour described in RFC3315, section 20.1.1, second paragraph. Here's the difference: RFC3315: relay MUST include interface-id if the link-address in server's response is not sufficient to select downlink interface. prefix-pool-opt-02: relay SHOULD include interface-id, so the the server can identify the relay itself (tomek: that's wrong. Interface-id is for interface or subnet identification, not relay identification. Relay-id is used for that purpose, see RFC5460, section 5.4.1) if the server would not like to use the link-address field specified in RELAY-FORW message (tomek: that imprecise or wrong. The server is not at liberty to "not use link-address field". There's a specific algorithm defined in section 11 of RFC3315 that the server must follow it). Tomek From volz@cisco.com Wed Apr 17 04:48:37 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DA521F8AA6 for ; Wed, 17 Apr 2013 04:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYIwWo8og0-2 for ; Wed, 17 Apr 2013 04:48:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EA9D821F8A8A for ; Wed, 17 Apr 2013 04:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8956; q=dns/txt; s=iport; t=1366199316; x=1367408916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ccruaS3RAoUAzJikRVaYba6RLwPC7DQTfzhuVPEiww0=; b=LKDPFGrmHvoLDNwljnmEihYsmZYpWkugIUyYxIZGBhf+p1mj+ZdwgCe4 LiRBCfOEiAoimWUqPJTAuYjTAf5OSyMqisl4Hpz1I22LqFydiG6eyJk1e 4hLbKs0tjeCjY7mGqT2RHlOosno2d1F/Xl3cB0LyKsCA794BIoQ+/G6fd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAO2KblGtJXG+/2dsb2JhbAA2EAqDBjbBDIEFFnSCHwEBAQMBAQEBNzQLBQcEAgEIEQQBAQEeCQchBgsUCQgBAQQOBYgCAwkGDC+zCw2JXYxHgREGgQkoBgUHBoJfYQOTOYFqgWOLcgaFHIFVgTaBcw X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="199765791" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 17 Apr 2013 11:48:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3HBmZt5003470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 11:48:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 06:48:34 -0500 From: "Bernie Volz (volz)" To: Leaf Yeh Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac45Cz/py3/bdmb7QvCqM9bmbO85vQBX/aqAAD2RoOQ= Date: Wed, 17 Apr 2013 11:48:33 +0000 Message-ID: <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> In-Reply-To: <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:48:37 -0000 Fyi -=20 > To be more readable, the server can alternatively > use the Interface ID option included in the RELAY-FORW message by the > relay agent to identify the relay agent itself=20 The interface id option can not be used to identify the relay. There is no = requirement that the interface id is globally unique - it only has signific= ance to the relay itself. - Bernie On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" wrote: > Tomek - How about "Misconfigured or compromised DHCPv6 server can cause > relays to start announcing arbitrary prefixes, including default routes, > which could lead to traffic hijack."? >=20 > I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't bought= in > the part of 'Compromised DHCPv6 server'. I don't believe the ORO option > included by the relay could compromise the DHCPv6 server. Right? >=20 >=20 >> Tomek - ...this draft repeats normative language from RFC3315 (e.g.=20 >> "The relay agent SHOULD include the Interface ID option")... >=20 > Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: > "The server MAY use the link-address specified in RELAY-FORW message > to identify the relay agent itself or its particular customer-facing > interface where the prefix pool is associated, but the server has to > maintain the binding data of prefix pools in association with these > link-addresses. To be more readable, the server can alternatively > use the Interface ID option included in the RELAY-FORW message by the > relay agent to identify the relay agent itself or its particular > customer-facing interface where the prefix pool is associated. In > order to give a meaningful reply, the server has to maintain the > binding data of prefix pools in association with the information > derived from the Interface ID option." > The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both us= e > cases shown in section 3. >=20 >=20 > Tomek -RFC3315: relay MUST include interface-id if the link-address in > server's response is not sufficient to select downlink interface. > prefix-pool-opt-02: relay SHOULD include interface-id, so the the server = can > identify the relay itself=20 > (tomek: that's wrong. Interface-id is for interface or subnet > identification, not relay identification. Relay-id is used for that purpo= se, > see RFC5460, section 5.4.1) >=20 > There might be a small debate here. The question could be whether the ser= ver > could identify the relay after receiving the interface-id of it. I guess = our > smart server already support that in the real deployment. [Pls. refer to > 'Access Node identifier' in BBF TR-177 > (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: The > BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be able to > use Option 18 in order to retrieve the Access Node identifier and access > this table in order to identify the ad-hoc pool of prefixes or addresses.= ] >=20 > OTOH, I believe relay-id defined in RFC5460 can also be used in the case = 1 > (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. 2); thoug= h > if the mechanism of Bulk-Lease-Query is employed, the relay also need to > include OPTION_ RELAY_ID in the relay-forward message for the basic > operation of DHCPv6 prefix or address assignment.=20 >=20 >=20 > Tomek - ... if the server would not like to use the link-address field > specified in RELAY-FORW message=20 > (tomek: that imprecise or wrong. The server is not at liberty to "not use > link-address field". There's a specific algorithm defined in section 11 o= f > RFC3315 that the server must follow it). >=20 > Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, has t= he > following text:=20 > " A server selects addresses to be assigned to an IA according to the > address assignment policies determined by the server administrator > and the specific information the server determines about the client > from some combination of the following sources: > - The link to which the client is attached. ... If the server receives > the message from a forwarding relay=20 > agent, then the client is on the same link as the one to which > the interface, identified by the link-address field in the > message from the relay agent, is attached... > - The DUID supplied by the client. > - Other information in options supplied by the client. > - Other information in options supplied by the relay agent." > The above text sounds not put link-address ahead of options supplied by t= he > relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF TR-177, its R-0= 7, > R-08 & section6.6 (...In some deployments there is neither a need nor a > desire to configure a global or unique local address to the interface on > which the client messages are received. Such a deployment does not allow = the > BNG to insert an IPv6 address in the link-address field...).] >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 > Sent: Sunday, April 14, 2013 8:26 PM > To: Leaf Yeh > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - > Respond by April 8, 2013 >=20 > On 13-04-12 03:15, Leaf Yeh wrote: >> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option?=20 >> Your relay will hijack the whole network? ... >>=20 >> The relay's behavior is still under control by the server. If it got=20 >> the wrong configuration, the server could also send out ::/0 in the=20 >> IA_PD. So this may sound an administration error. We just want the=20 >> prefix pools not configure to be ::/0 or any overlap between them. I=20 >> feel a little stuck on the exact text you want. How about 'The=20 >> administrator of the DHCPv6 server should pay more attention to the=20 >> configuration of the prefix pools, for examples, a. ::/0 may cause a=20 >> big routing problem in the whole ISP network; b. the configuration of=20 >> prefix pool should avoid overlap in the address plan, and etc.' ? I am > not quite sure... > Administrator mistake is one concern, the other one is that DHCPv6 server > may become an attractive attack target when prefix-pool is deployed. >=20 > How about "Misconfigured or compromised DHCPv6 server can cause relays to > start announcing arbitrary prefixes, including default routes, which coul= d > lead to traffic hijack."? >=20 >> Tomek - Bernie had this concern and I tend to agree with him... the=20 >> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my=20 >> reply to Bernie's email. Thanks for your suggestion here. Do we need=20 >> more explanation on the mathematic function of floor() ? :-) > I don't think so. A potential implementor who doesn't know what floor() > function does should probably consider starting a career in some other > industry. :-) >=20 >> Tomek - ...(I know that requestor in most cases is part of a relay,=20 >> but from protocol perspective these are separate entities)...Yes.=20 >> Please split actions taken by requestor into separate section. It can=20 >> be subsection 5.1 if you like to. >>=20 >> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the=20 >> section 5 "Relay Agent Behavior" (just for an editorial change)? Do=20 >> you want section >> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? > Yes to both. >=20 >> Tomek - ...this draft repeats normative language from RFC3315 (e.g.=20 >> "The relay agent SHOULD include the Interface ID option")... >>=20 >> After searching and reading, I still can't find this sentence in RFC3315= . > It is in prefix-pool-opt-02, section 5, second paragraph. Text from > prefix-pool-opt-02 is an imprecise subset of behaviour described in RFC33= 15, > section 20.1.1, second paragraph. Here's the difference: >=20 > RFC3315: relay MUST include interface-id if the link-address in server's > response is not sufficient to select downlink interface. >=20 > prefix-pool-opt-02: relay SHOULD include interface-id, so the the server = can > identify the relay itself (tomek: that's wrong. Interface-id is for > interface or subnet identification, not relay identification. Relay-id is > used for that purpose, see RFC5460, section 5.4.1) if the server would no= t > like to use the link-address field specified in RELAY-FORW message (tomek= : > that imprecise or wrong. The server is not at liberty to "not use > link-address field". There's a specific algorithm defined in section 11 o= f > RFC3315 that the server must follow it). >=20 > Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Apr 17 06:02:27 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3533A21F8E62 for ; Wed, 17 Apr 2013 06:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyML1csP-2AU for ; Wed, 17 Apr 2013 06:02:26 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id A21FA21F8E67 for ; Wed, 17 Apr 2013 06:02:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUW6dYrjJnauZ4Idaz40ORo+bOV9g2iM0@postini.com; Wed, 17 Apr 2013 06:02:26 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 40539F8002 for ; Wed, 17 Apr 2013 06:02:26 -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 37F72190061 for ; Wed, 17 Apr 2013 06:02:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 06:02:26 -0700 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJp/YY1cyxg9k6UgkiMhZ9juZjapV6AgABGcoA= Date: Wed, 17 Apr 2013 13:02:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514CF20@mbx-01.win.nominum.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C887A01E6153A47BA1B089512287681@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:02:27 -0000 I also support adoption. From Ted.Lemon@nominum.com Wed Apr 17 06:03:33 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125EC21E8047 for ; Wed, 17 Apr 2013 06:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ulUz8g1vcFJE for ; Wed, 17 Apr 2013 06:03:32 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 37B5721E804E for ; Wed, 17 Apr 2013 06:03:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUW6do7w97H527/Lxqbobaqm7EjFUkERD@postini.com; Wed, 17 Apr 2013 06:03:32 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 205511B8107 for ; Wed, 17 Apr 2013 06:03:31 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1A0B2190061 for ; Wed, 17 Apr 2013 06:03:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 06:03:31 -0700 From: Ted Lemon To: dhcwg Thread-Topic: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 Thread-Index: AQHOO0llJTmrn2xIkEuAdoUIFfRESJja1rAA Date: Wed, 17 Apr 2013 13:03:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514CF53@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> <5162F5DB.7010404@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AA19456@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:03:33 -0000 As an author, I guess it goes without saying that I support adoption, but I= 'll say so anyway to make the chairs' job easier in terms of determining co= nsensus. From volz@cisco.com Wed Apr 17 06:32:58 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6F21F8721 for ; Wed, 17 Apr 2013 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVOdd5uuX33b for ; Wed, 17 Apr 2013 06:32:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBD421F871C for ; Wed, 17 Apr 2013 06:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4475; q=dns/txt; s=iport; t=1366205577; x=1367415177; h=from:to:subject:date:message-id:mime-version; bh=5Z6nUdnksa9Xu6tpVvAmzil2L5LlBAmKXwiZ/XgmAic=; b=lRhsIIxtxOKG2GjFiIZStSUBlVad+NI3Nt5eZqz9aPu03v//drSC5RL3 GsKprXfaDg2+7VkWiFLwErU8fNbyCU6kyHC+/QiWtfWxARTyBpBcrZEUp dfvw6dgOgRJKGVMwJwd6SW98LgFP5elOrzbER4d+1m3OVJtX+4QyxhQ3h w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAEajblGtJV2d/2dsb2JhbABQgkJENrhfAYgsgQQWdIIhAQQdEF4BKlYmAQQbiAwMnDChGo1ogQGDHWEDmCmPcYFVgTaBczU X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208,217";a="199776615" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 17 Apr 2013 13:32:56 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3HDWuRZ010617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 13:32:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 08:32:56 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 Thread-Index: Ac47b6ONLSN8YQAvTLWyulsavR6P7g== Date: Wed, 17 Apr 2013 13:32:56 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1850BDF8xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:32:58 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1850BDF8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all: The authors have requested a call for adoption by the WG for draft-bhandari= -dhc-access-network-identifier-04. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that the 04 draft was just published and has redesigned options to bet= ter follow the option guidelines. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-bhandari-dhc-access-network-identifier-04. Regards, Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1850BDF8xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all:

 

The authors have requested a call for adoption by= the WG for draft-bhandari-dhc-access-network-identifier-04.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that the 04 draft was just published and has= redesigned options to better follow the option guidelines.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04<= /a>.

 

Regards,

Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E1850BDF8xmbrcdx04ciscoc_-- From volz@cisco.com Wed Apr 17 06:47:53 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0021F8576 for ; Wed, 17 Apr 2013 06:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGQDV2BUwEXB for ; Wed, 17 Apr 2013 06:47:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 56E4521F8488 for ; Wed, 17 Apr 2013 06:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5860; q=dns/txt; s=iport; t=1366206471; x=1367416071; h=from:to:subject:date:message-id:mime-version; bh=LJ51Gn5D12Z1TJnFokay+rPmPhyY0ARLWDiQwbS257M=; b=c3FvdydzDDAE+uOJ+y2vQKqNcanRbOGw6jX1z51UAeqkRJWF31RtwW+g ZsShLHV2nzM++21qT1bOd1092dMDsYKttcdWo/nHjCwRsBF4oMf076bSG h2qYKfbMyprv8d0eLp+Dhg4NCBjoCxPZ1ZFC8Rv5vJY1f2MA447ZSgx9C A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFABmnblGtJV2c/2dsb2JhbABQgkJENrhfAYgsgQQWdIIhAQQdED4DHQEqViYBBBuIDAycK6EajWiBAYMdYQOYKY9xgwuBczU X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208,217";a="199793472" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 17 Apr 2013 13:47:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3HDlnSv016344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 13:47:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 08:47:49 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 Thread-Index: Ac47cakbzWTp4LTBSsq8GkSDmdc1YA== Date: Wed, 17 Apr 2013 13:47:49 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1850BFB8xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:47:53 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1850BFB8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all: The author has requested a call for adoption by the WG for draft-lemon-dhc-= topo-conf-01. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that when Ted first published this draft, he posted the following to t= he DHC WG list: I just submitted a new document to the tracker that attempts to document ex= isting practice with respect to how DHCP options are derived and sent to cl= ients in modern DHCP servers. This is a first draft, and probably needs s= ome new examples. People on this mailing list will, I suspect, find it di= fficult to remain awake while reading it because it is such old hat to us, = but it's been brought to my attention recently that not everybody in the IE= TF is an expert on DHCP server configuration; this document is an attempt t= o provide a short, pithy tutorial for IETF document writers who are interes= ted in understanding how DHCP is used in practice. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-lemon-dhc-topo-conf Regards, Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1850BFB8xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all:

 

The author has requested a call for adoption by t= he WG for draft-lemon-dhc-topo-conf-01.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that when Ted first published this draft, he= posted the following to the DHC WG list:

 

I just submitted a new= document to the tracker that attempts to document existing practice with r= espect to how DHCP options are derived and sent to clients in modern DHCP s= ervers.   This is a first draft, and probably needs some new examples.   People on this mailing list = will, I suspect, find it difficult to remain awake while reading it because= it is such old hat to us, but it's been brought to my attention recently t= hat not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a sho= rt, pithy tutorial for IETF document writers who are interested in understa= nding how DHCP is used in practice.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-lemon-dhc-topo-conf

 

Regards,

Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E1850BFB8xmbrcdx04ciscoc_-- From stenc@s-carlsen.dk Wed Apr 17 07:08:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA521F8B25 for ; Wed, 17 Apr 2013 07:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKTjUl-sSb-p for ; Wed, 17 Apr 2013 07:08:48 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4EF21F8B13 for ; Wed, 17 Apr 2013 07:08:43 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id D976BD5 for ; Wed, 17 Apr 2013 16:08:39 +0200 (CEST) Message-ID: <516EACE7.1080800@s-carlsen.dk> Date: Wed, 17 Apr 2013 16:08:39 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------050907010709030507080303" Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:08:50 -0000 This is a multi-part message in MIME format. --------------050907010709030507080303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I favor adoption. I find such a document useful as a guide. On 17/04/13 15:47, Bernie Volz (volz) wrote: > > Hi all: > > > > The author has requested a call for adoption by the WG for > draft-lemon-dhc-topo-conf-01. > > > > This call is being initiated to confirm whether there is WG consensus > to adopt this work as DHC WG draft. Please state whether or not you're > in favor of the adoption by replying to this mail. If you are not in > favor, please also state your objections in your response. This > adoption call will complete on May 2^nd , 2013. > > > > Note that when Ted first published this draft, he posted the following > to the DHC WG list: > > > > I just submitted a new document to the tracker that attempts to > document existing practice with respect to how DHCP options are > derived and sent to clients in modern DHCP servers. This is a first > draft, and probably needs some new examples. People on this mailing > list will, I suspect, find it difficult to remain awake while reading > it because it is such old hat to us, but it's been brought to my > attention recently that not everybody in the IETF is an expert on DHCP > server configuration; this document is an attempt to provide a short, > pithy tutorial for IETF document writers who are interested in > understanding how DHCP is used in practice. > > > > The HTML version of the document can be viewed at > http://tools.ietf.org/html/draft-lemon-dhc-topo-conf > > > > > Regards, > > Tomek & Bernie > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------050907010709030507080303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I favor adoption.

I find such a document useful as a guide.


On 17/04/13 15:47, Bernie Volz (volz) wrote:

Hi all:

 

The author has requested a call for adoption by the WG for draft-lemon-dhc-topo-conf-01.

 

This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on May 2nd, 2013.

 

Note that when Ted first published this draft, he posted the following to the DHC WG list:

 

I just submitted a new document to the tracker that attempts to document existing practice with respect to how DHCP options are derived and sent to clients in modern DHCP servers.   This is a first draft, and probably needs some new examples.   People on this mailing list will, I suspect, find it difficult to remain awake while reading it because it is such old hat to us, but it's been brought to my attention recently that not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a short, pithy tutorial for IETF document writers who are interested in understanding how DHCP is used in practice.

 

The HTML version of the document can be viewed at http://tools.ietf.org/html/draft-lemon-dhc-topo-conf

 

Regards,

Tomek & Bernie

 



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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------050907010709030507080303-- From Tina.Tsou.Zouting@huawei.com Wed Apr 17 07:11:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572E21F8BAE for ; Wed, 17 Apr 2013 07:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 NlCkrjAtKxIq for ; Wed, 17 Apr 2013 07:11:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7716E21F8B13 for ; Wed, 17 Apr 2013 07:10:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARX88654; Wed, 17 Apr 2013 14:10:58 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Apr 2013 15:10:45 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Apr 2013 15:10:56 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.156]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Wed, 17 Apr 2013 07:10:50 -0700 From: Tina TSOU To: Ted Lemon Thread-Topic: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 Thread-Index: AQHOMJJssDuDWqLB9EKSw7ILnkoUWJjapV6AgABGcwD//53Fjw== Date: Wed, 17 Apr 2013 14:10:50 +0000 Message-ID: <9351AEFB-C195-4515-9D0A-291DD61F4347@huawei.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> , <8D23D4052ABE7A4490E77B1A012B63077514CF20@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514CF20@mbx-01.win.nominum.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:11:00 -0000 Dear all, I support the adoption. Thank you, Tina On Apr 17, 2013, at 6:03 AM, "Ted Lemon" wrote: > I also support adoption. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Apr 17 07:59:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E5B21F8573 for ; Wed, 17 Apr 2013 07:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 nbeRCW1Tis46 for ; Wed, 17 Apr 2013 07:59:47 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AB24A21F8550 for ; Wed, 17 Apr 2013 07:59:47 -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 DSNKUW6432RgZo+nkRj/vMH+zk4hUiuRJOiN@postini.com; Wed, 17 Apr 2013 07:59:47 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 3B8851B80EA for ; Wed, 17 Apr 2013 07:59:42 -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 312F5190061; Wed, 17 Apr 2013 07:59:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 07:59:42 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 Thread-Index: Ac47b6ONLSN8YQAvTLWyulsavR6P7gARzhcA Date: Wed, 17 Apr 2013 14:59:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:59:49 -0000 When we talked about this earlier, I said that it might be better to have t= his work done in DHC rather than forcing it to find a new working group bec= ause it seemed to be something that was being asked for by other SDOs. Ho= wever, the authors never said anything about that over and above what they'= ve already said in meetings, so I don't actually have a clear picture of wh= o is asking for this. Looking in the data tracker, I don't find any liais= on statement requesting that this work be done. The authors have expressed a great deal of urgency about this work, and I d= on't want to delay it any further, so I will state that as a participant, I= 'm in favor of the working group taking on the work. However, with my AD = hat on, I would like to get some kind of actual request for help from the S= DOs who want this functionality before the end of the call for adoption. = Otherwise I think Bernie's concern that the DHC working group really isn't = qualified to evaluate the validity of the option contents will remain unadd= ressed, and I think it's a valid concern. The request from the SDOs should be of the form "we need DHCP options to de= liver the following bits of functionality," and should briefly describe the= functionality that's needed, and refer to the documents that the SDO is wo= rking on that support this need. If this need is not really coming from these SDOs, but rather from some IET= F working group, then perhaps Bernie's original observation was correct, an= d this work should be done in that working group instead. From sgundave@cisco.com Wed Apr 17 08:47:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B9A21F8C35 for ; Wed, 17 Apr 2013 08:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uBL6vTcafms for ; Wed, 17 Apr 2013 08:47:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2884B21F8C08 for ; Wed, 17 Apr 2013 08:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3113; q=dns/txt; s=iport; t=1366213651; x=1367423251; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jr1DzSKSeYrDKtZvgGMMNlUq/PRKsR82w+5jDnYnxu4=; b=IIsLKO2teHuESFvhdVeNdyAF7LDYr04AFHNQv0N76UYy9nkDuZ9wixip 0OPLxZ5O46MxVMXDDvsDTU/BG4l4qdbQLSwALZFcBTt6Iqz9dqYkBqS0/ dWKj+o9uP+joXRLIl7z3qLIJpsqN36H+CqPxor/1jIZbrgv1Cmrj6zYv1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAD/DblGtJV2Z/2dsb2JhbABQgwY2wEOBAxZ0giEBBAEBARodLQYBCxIBCCIUNwslAgQBDQUIE4d5DL1XBI5pMQeCZWEDqBqBVYE2gig X-IronPort-AV: E=Sophos;i="4.87,494,1363132800"; d="scan'208";a="199849809" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 17 Apr 2013 15:47:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3HFlUHO032318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 15:47:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 10:47:30 -0500 From: "Sri Gundavelli (sgundave)" To: Ted Lemon , "Bernie Volz (volz)" Thread-Topic: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 Thread-Index: AQHOO4LdLSN8YQAvTLWyulsavR6P7g== Date: Wed, 17 Apr 2013 15:47:29 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Florin Baboescu , Jouni Korhonen Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:47:32 -0000 Hi Ted, Thanks for your comments. This requirement is not coming from any SDO. We believe this is a generic requirement for IETF based IP architectures. As you are aware, many operators are deploying large scale SP WiFI networks. These deployments are based on standard IETF protocols and architectures (tunneling, mobility, Routing, AAA protocols ...). In many of these deployments the subscriber services are tied to the access network, for example, the initial portal page may be different based on the user location (SSID, AP Mac address ..). These parameters are typically carried on DHCP option-82, and are coded in a vendor basis. There is no standard encoding that a backend system can reliably depend on for learning these parameters. In the past when WiFI was largely contained to enterprises, with single vendor solutions, this worked fine. But, now in many deployments there are multi-vendor systems and interop is required. The draft is trying to attempt to fix that gap. We want to drive this work in DHC, not using a liaison statement, but as a gap in IETF protocols, to solve a practical deployment issue and improve interoperability. I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI networks and he can comment on this. Regards Sri On 4/17/13 7:59 AM, "Ted Lemon" wrote: >When we talked about this earlier, I said that it might be better to have >this work done in DHC rather than forcing it to find a new working group >because it seemed to be something that was being asked for by other SDOs. > However, the authors never said anything about that over and above what >they've already said in meetings, so I don't actually have a clear >picture of who is asking for this. Looking in the data tracker, I don't >find any liaison statement requesting that this work be done. > >The authors have expressed a great deal of urgency about this work, and I >don't want to delay it any further, so I will state that as a >participant, I'm in favor of the working group taking on the work. >However, with my AD hat on, I would like to get some kind of actual >request for help from the SDOs who want this functionality before the end >of the call for adoption. Otherwise I think Bernie's concern that the >DHC working group really isn't qualified to evaluate the validity of the >option contents will remain unaddressed, and I think it's a valid concern. > >The request from the SDOs should be of the form "we need DHCP options to >deliver the following bits of functionality," and should briefly describe >the functionality that's needed, and refer to the documents that the SDO >is working on that support this need. > >If this need is not really coming from these SDOs, but rather from some >IETF working group, then perhaps Bernie's original observation was >correct, and this work should be done in that working group instead. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Wed Apr 17 09:18:33 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B19D21F8C23 for ; Wed, 17 Apr 2013 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtYw4-eMpA9g for ; Wed, 17 Apr 2013 09:18:33 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id C0A5D21F8C08 for ; Wed, 17 Apr 2013 09:18:32 -0700 (PDT) Received: from mail-qc0-f197.google.com ([209.85.216.197]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUW7LWFgd8aschxUeOHBCQIahHHPkrxQM@postini.com; Wed, 17 Apr 2013 09:18:32 PDT Received: by mail-qc0-f197.google.com with SMTP id b14so611929qcs.8 for ; Wed, 17 Apr 2013 09:18:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=FIvlRoh6fHT4eNC/IFWvWlUWPDQ6FMwBrZBJK9cFXSo=; b=X63cy7XCXLhvD1VSuOypqDGL6fNinjHjUEBmE2RvsDT+8XaT9+pbLRetjzscKnGg7b IksO9qnFcWtieVGSlXR8xyUY8M44TFoDp+9HSE6FM8N8BS0LXeQ3KFQwfz3y6MViE4Nk i6wnnt/vUy+sR3RBBuwT1Y9ea6u5XLlGUix16M7E0hgWRM32fSFSIBnIICwT3rMUd7Ys EmBPyV8G5j5zaJ5wMoLbFfiYkHGQl9AojWle9NQ/i8DydNTzeQV2eK0RhILT/d2qxpaj R0K4Cb/cm7VIPv6U6m1tMXx6KBwdHI+zFBQw4qrSi/fejsdiduam9TP9N4Cc/3QJvWku gSMA== X-Received: by 10.220.221.210 with SMTP id id18mr5350310vcb.74.1366215511463; Wed, 17 Apr 2013 09:18:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.221.210 with SMTP id id18mr5350304vcb.74.1366215511389; Wed, 17 Apr 2013 09:18:31 -0700 (PDT) Received: by 10.220.56.10 with HTTP; Wed, 17 Apr 2013 09:18:31 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514CF53@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> <5162F5DB.7010404@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AA19456@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B63077514CF53@mbx-01.win.nominum.com> Date: Wed, 17 Apr 2013 09:18:31 -0700 Message-ID: From: Andre Kostur To: dhcwg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnUYliyDzm+++fN2Suju0uYFWyJvizBOcM9SmsVfZ2j6YC/ism2oEGXcw4wrBBnJg/uaU5yZtCtlHYuooAQ1ePvRLwVhfQyWWocYDxL8mRhpDvwrARUEHbUtJjcm6eF35pYkcGP7Zt6EwNi1V0I4izk6+UDsQ== Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:18:33 -0000 I support adoption. -- Andre Kostur From sarikaya2012@gmail.com Wed Apr 17 14:22:46 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5521E80DE for ; Wed, 17 Apr 2013 14:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 h8-FEantjO4c for ; Wed, 17 Apr 2013 14:22:45 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id CE30721E80B1 for ; Wed, 17 Apr 2013 14:22:43 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z13so2076052lbh.27 for ; Wed, 17 Apr 2013 14:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dqDk/LRQWf01yA6k8jTqBQUy1xTMU+DZxfdgIDUMUw0=; b=MmuF1ZCCnt//VIuNnvr/zn/iH95ptmKHoM6d930/XpSBJULn0WIZ73MS5OENnUMllt /SL3wgbGp+rWZjDAZYM58S7rItAwfC5BS8gqAeUwFhoWq5u7JUVhj1LkH/+UkC8SDfZk H+QccAopkn3lOe+LXGwsa23J4Fl9VR2TIuCgFq2dDtQM1JwKMvWQABCoYJQDMtkfOTop E1G+kvqIoba6bvhx6ibjkTtCrpTVEPIGW0JkZk9i6e61w34n12gU6yN5skvEYzU7DLEJ 3nraLmoThj60UCO6mUmpINa059DzR359BNi09Car6b0Ltjd/jpcONA8I7DbKpkA8wEj/ 5vtA== MIME-Version: 1.0 X-Received: by 10.112.74.98 with SMTP id s2mr4529889lbv.9.1366233762724; Wed, 17 Apr 2013 14:22:42 -0700 (PDT) Received: by 10.114.175.140 with HTTP; Wed, 17 Apr 2013 14:22:42 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> Date: Wed, 17 Apr 2013 16:22:42 -0500 Message-ID: From: Behcet Sarikaya To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=14dae94738cd1b82c504da951692 Cc: "dhcwg@ietf.org" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 21:22:46 -0000 --14dae94738cd1b82c504da951692 Content-Type: text/plain; charset=ISO-8859-1 Hi Sri, I think that Client/Server behaviour (Section 7 & 9) in the draft needs some clarification. Please check Bernie's mail: http://www.ietf.org/mail-archive/web/dhcwg/current/msg11144.html on draft-ietf-dhc-80211-option-01.txt. Also please check the operation described in Li's draft: http://tools.ietf.org/html/draft-xue-dhc-location-option-01 Regards, Behcet On Wed, Apr 17, 2013 at 10:47 AM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Hi Ted, > > Thanks for your comments. > > This requirement is not coming from any SDO. We believe this is a generic > requirement for IETF based IP architectures. > > As you are aware, many operators are deploying large scale SP WiFI > networks. These deployments are based on standard IETF protocols and > architectures (tunneling, mobility, Routing, AAA protocols ...). In many > of these deployments the subscriber services are tied to the access > network, for example, the initial portal page may be different based on > the user location (SSID, AP Mac address ..). These parameters are > typically carried on DHCP option-82, and are coded in a vendor basis. > There is no standard encoding that a backend system can reliably depend on > for learning these parameters. In the past when WiFI was largely contained > to enterprises, with single vendor solutions, this worked fine. But, now > in many deployments there are multi-vendor systems and interop is > required. The draft is trying to attempt to fix that gap. We want to drive > this work in DHC, not using a liaison statement, but as a gap in IETF > protocols, to solve a practical deployment issue and improve > interoperability. > > I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI > networks and he can comment on this. > > > > > Regards > Sri > > > > > > > > > > > > On 4/17/13 7:59 AM, "Ted Lemon" wrote: > > >When we talked about this earlier, I said that it might be better to have > >this work done in DHC rather than forcing it to find a new working group > >because it seemed to be something that was being asked for by other SDOs. > > However, the authors never said anything about that over and above what > >they've already said in meetings, so I don't actually have a clear > >picture of who is asking for this. Looking in the data tracker, I don't > >find any liaison statement requesting that this work be done. > > > >The authors have expressed a great deal of urgency about this work, and I > >don't want to delay it any further, so I will state that as a > >participant, I'm in favor of the working group taking on the work. > >However, with my AD hat on, I would like to get some kind of actual > >request for help from the SDOs who want this functionality before the end > >of the call for adoption. Otherwise I think Bernie's concern that the > >DHC working group really isn't qualified to evaluate the validity of the > >option contents will remain unaddressed, and I think it's a valid concern. > > > >The request from the SDOs should be of the form "we need DHCP options to > >deliver the following bits of functionality," and should briefly describe > >the functionality that's needed, and refer to the documents that the SDO > >is working on that support this need. > > > >If this need is not really coming from these SDOs, but rather from some > >IETF working group, then perhaps Bernie's original observation was > >correct, and this work should be done in that working group instead. > > > >_______________________________________________ > >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 > --14dae94738cd1b82c504da951692 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sri,

I think that Client/Server behaviour (Section 7 & 9) in = the draft needs some clarification.

Please check Bernie's mail:<= br>http://www.ietf.org/mail-archive/web/dhcwg/current/msg11144.html on draft-ietf-dhc-80211-option-01.txt.

Also please check the operati= on described in Li's draft:
http://tools.ietf.org/html/draft-xue-dhc-lo= cation-option-01

Regards,

Behcet
On Wed, Apr 17, 20= 13 at 10:47 AM, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:
Hi Ted,

Thanks for your comments.

This requirement is not coming from any SDO. We believe this is a generic requirement for IETF based IP architectures.

As you are aware, many operators are deploying large scale SP WiFI
networks. These deployments are based on standard IETF protocols and
architectures (tunneling, mobility, Routing, AAA protocols ...). In many of these deployments the subscriber services are tied to the access
network, for example, the initial portal page may be different based on
the user location (SSID, AP Mac address ..). These parameters are
typically carried on DHCP option-82, and are coded in a vendor basis.
There is no standard encoding that a backend system can reliably depend on<= br> for learning these parameters. In the past when WiFI was largely contained<= br> to enterprises, with single vendor solutions, this worked fine. But, now in many deployments there are multi-vendor systems and interop is
required. The draft is trying to attempt to fix that gap. We want to drive<= br> this work in DHC, not using a liaison statement, but as a gap in IETF
protocols, to solve a practical deployment issue and improve
interoperability.

I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI
networks and he can comment on this.




Regards
Sri











On 4/17/13 7:59 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

>When we talked about this earlier, I said that it might be better to ha= ve
>this work done in DHC rather than forcing it to find a new working grou= p
>because it seemed to be something that was being asked for by other SDO= s.
> =A0However, the authors never said anything about that over and above = what
>they've already said in meetings, so I don't actually have a cl= ear
>picture of who is asking for this. =A0 Looking in the data tracker, I d= on't
>find any liaison statement requesting that this work be done.
>
>The authors have expressed a great deal of urgency about this work, and= I
>don't want to delay it any further, so I will state that as a
>participant, I'm in favor of the working group taking on the work.<= br> >However, with my AD hat on, I would like to get some kind of actual
>request for help from the SDOs who want this functionality before the e= nd
>of the call for adoption. =A0 Otherwise I think Bernie's concern th= at the
>DHC working group really isn't qualified to evaluate the validity o= f the
>option contents will remain unaddressed, and I think it's a valid c= oncern.
>
>The request from the SDOs should be of the form "we need DHCP opti= ons to
>deliver the following bits of functionality," and should briefly d= escribe
>the functionality that's needed, and refer to the documents that th= e SDO
>is working on that support this need.
>
>If this need is not really coming from these SDOs, but rather from some=
>IETF working group, then perhaps Bernie's original observation was<= br> >correct, and this work should be done in that working group instead. >
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg

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

--14dae94738cd1b82c504da951692-- From baboescu@broadcom.com Wed Apr 17 16:05:36 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9721F89DE for ; Wed, 17 Apr 2013 16:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 YcyrrgQv87CO for ; Wed, 17 Apr 2013 16:05:35 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5E21F89DB for ; Wed, 17 Apr 2013 16:05:35 -0700 (PDT) Received: from [10.9.208.53] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 17 Apr 2013 16:01:59 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 17 Apr 2013 16:05:27 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 17 Apr 2013 16:05:26 -0700 From: "Florin Baboescu" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 Thread-Index: AQHOO4NsLSN8YQAvTLWyulsavR6P7pjbBrrQ Date: Wed, 17 Apr 2013 23:05:25 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> <24C0F3E22276D9438D6F366EB89FAEA810233F63@xmb-aln-x03.cisco.com> In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA810233F63@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7D71F66D31W3617051-01-01 Content-Type: multipart/alternative; boundary=_000_FF83B7C4E3E20340A64DE85B768F08282AC7C126SJEXCHMB09corpa_ X-Mailman-Approved-At: Wed, 17 Apr 2013 16:16:26 -0700 Cc: "volz@cisco.com" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 23:05:36 -0000 --_000_FF83B7C4E3E20340A64DE85B768F08282AC7C126SJEXCHMB09corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I would like to express my support for this work as it addresses a practica= l deployment issue. Thank you. -Florin Baboescu From: "Bernie Volz (volz)" > Date: Wednesday, April 17, 2013 6:32 AM To: "dhcwg@ietf.org" > Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-ident= ifier-04 - Ends May 2, 2013 Hi all: The authors have requested a call for adoption by the WG for draft-bhandari= -dhc-access-network-identifier-04. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that the 04 draft was just published and has redesigned options to bet= ter follow the option guidelines. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-bhandari-dhc-access-network-identifier-04. Regards, Tomek & Bernie --_000_FF83B7C4E3E20340A64DE85B768F08282AC7C126SJEXCHMB09corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I would like to express my support for this wo= rk as it addresses a practical deployment issue.

Thank you.

 

-Florin Baboescu

 

 

&n= bsp;

&n= bsp;

From: "Bernie Volz (volz)" <volz@cisco.com>
Date: Wednesday, April 17, 2013 6:32 AM
To: "dhcwg@ietf.org"= <dhcwg@ietf.org>
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-networ= k-identifier-04 - Ends May 2, 2013

&n= bsp;

Hi all:

 

The authors have requ= ested a call for adoption by the WG for draft-bhandari-dhc-access-network-i= dentifier-04.

 

This call is being in= itiated to confirm whether there is WG consensus to adopt this work as DHC = WG draft. Please state whether or not you're in favor of the adoption by re= plying to this mail. If you are not in favor, please also state your objections in your response. This adoptio= n call will complete on May 2nd, 2013.

 

Note that the 04 draf= t was just published and has redesigned options to better follow the option= guidelines.

 

The HTML version of t= he document can be viewed at http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04<= /a>.

 

Regards,

Tomek & Bernie

 =

--_000_FF83B7C4E3E20340A64DE85B768F08282AC7C126SJEXCHMB09corpa_-- From ghalwasi@cisco.com Wed Apr 17 19:07:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC6221E80ED for ; Wed, 17 Apr 2013 19:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTbxZbLBPP90 for ; Wed, 17 Apr 2013 19:07:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A8A8121E8090 for ; Wed, 17 Apr 2013 19:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1210; q=dns/txt; s=iport; t=1366250838; x=1367460438; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Z8kemSH8lLFlIz5ApLeRAsL8BqLsksZqF2ZHIRugxjg=; b=gSGczQn6LPcfrsYohofg/iBqK2hbnFG/O37YbxpZzfBjrSr2IGgu0gRE ZUXPDx3lwSHrfJ0hszjp5I7jplz0RMsRJxXNmsILfiH4PGkVY0SUUF0vS w1MDRroGXP3orIshfF38FGb8oSkTW3PSgsnYNEn4FhCHoHEe7TC80wxOe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAKhUb1GtJXG9/2dsb2JhbABQgwY2wFeBARZ0gh8BAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiIDAy9TgSNaIEBJhIGgl9hA6gagwuBczU X-IronPort-AV: E=Sophos;i="4.87,496,1363132800"; d="scan'208";a="200075412" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 18 Apr 2013 02:07:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3I27IU3020307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 02:07:18 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.197]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 21:07:17 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Tomek Mrugalski , dhcwg Thread-Topic: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 Thread-Index: AQHOMJBX3ZPAcYOlEkuhkVqplZfYiJjbUaqQ Date: Thu, 18 Apr 2013 02:07:16 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22EFC032@xmb-aln-x06.cisco.com> References: <31BA50D5-3451-49B7-8139-8244A3E90F7A@gmail.com> <515C6627.5060401@gmail.com> In-Reply-To: <515C6627.5060401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 02:07:20 -0000 I support adoption of this document. -Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Wednesday, April 03, 2013 10:56 PM To: dhcwg Subject: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315upda= te-00 Hi all, This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during la= st IETF meeting. We were somewhat surprised to note that RFC3315 does not c= larify how the relays should handle message types that they do not recogniz= e. This draft clarifies that unknown messages should be relayed as usual. Authors requested adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being initiate= d to confirm whether there is WG consensus to adopt this work as DHC WG dra= ft. Please state whether or not you're in favor of the adoption by replying= to this mail. If you are not in favor, please also state your objections in your response= . This adoption call will complete on 2013-04-17. Regards, Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Wed Apr 17 19:16:41 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6721E80E5 for ; Wed, 17 Apr 2013 19:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LQHBC4TlIJc for ; Wed, 17 Apr 2013 19:16:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7B21E80A2 for ; Wed, 17 Apr 2013 19:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10257; q=dns/txt; s=iport; t=1366251400; x=1367461000; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NUpz7BHf2EXUQe7zDtAb8PTIkodKsrbrcQUIg9aisEc=; b=KUfEdegqkKGp35o5oCB71+SM1NWpEvp7GHgjlLQJIvpO9xgGgC4nPZc5 40Il6XVKvTm1hmmmc3pJArOuPobf3CIe3v06p3JcfZI4e68Zj3G45dMNl LyhVVJ1mZsc4B5KC4hI6eyibfP1uZALezEloQ+K6sOvNZoBc3I+nf2Xvx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAO1Wb1GtJV2a/2dsb2JhbABQgkJENrgdAYg5gQEWdIIfAQEBBAEBARoQPgMbAgEIEQQBAQsdBycLFAkIAgQBEgiIDAy9WY1ogQEmBwoBgmVhA5gpj3GDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,496,1363132800"; d="scan'208,217";a="200049087" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 18 Apr 2013 02:16:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3I2GbgF021602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 02:16:37 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.197]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 21:16:36 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Sten Carlsen , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 Thread-Index: AQHOO3UeqmSrLUEdTk6bqfL4JuIH3ZjbPXWQ Date: Thu, 18 Apr 2013 02:16:36 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22EFC062@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> <516EACE7.1080800@s-carlsen.dk> In-Reply-To: <516EACE7.1080800@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.54] Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB22EFC062xmbalnx06ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 02:16:42 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB22EFC062xmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Why the Intended status of this document is Standards Track instead of Info= rmational ? -Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S= ten Carlsen Sent: Wednesday, April 17, 2013 7:39 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends Ma= y 2, 2013 I favor adoption. I find such a document useful as a guide. On 17/04/13 15:47, Bernie Volz (volz) wrote: Hi all: The author has requested a call for adoption by the WG for draft-lemon-dhc-= topo-conf-01. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that when Ted first published this draft, he posted the following to t= he DHC WG list: I just submitted a new document to the tracker that attempts to document ex= isting practice with respect to how DHCP options are derived and sent to cl= ients in modern DHCP servers. This is a first draft, and probably needs s= ome new examples. People on this mailing list will, I suspect, find it di= fficult to remain awake while reading it because it is such old hat to us, = but it's been brought to my attention recently that not everybody in the IE= TF is an expert on DHCP server configuration; this document is an attempt t= o provide a short, pithy tutorial for IETF document writers who are interes= ted in understanding how DHCP is used in practice. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-lemon-dhc-topo-conf Regards, Tomek & Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --_000_90903C21C73202418A48BFBE80AEE5EB22EFC062xmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1=

 = 

Why the Inten=
ded status of this document is Standards Track instead of Informational ?
 
-Gaurav

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf= .org] On Behalf Of Sten Carlsen
Sent: Wednesday, April 17, 2013 7:39 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - = Ends May 2, 2013

 

I favor adoption.

I find such a document useful as a guide.

On 17/04/13 15:47, Bernie Volz (volz) wrote:

Hi all:

 

The author has requested a call for adoption by t= he WG for draft-lemon-dhc-topo-conf-01.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that when Ted first published this draft, he= posted the following to the DHC WG list:

 

I just submitted a new= document to the tracker that attempts to document existing practice with r= espect to how DHCP options are derived and sent to clients in modern DHCP s= ervers.   This is a first draft, and probably needs some new examples.   People on this mailing list = will, I suspect, find it difficult to remain awake while reading it because= it is such old hat to us, but it's been brought to my attention recently t= hat not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a sho= rt, pithy tutorial for IETF document writers who are interested in understa= nding how DHCP is used in practice.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-lemon-dhc-topo-conf

 

Regards,

Tomek & Bernie

 




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



-- 
Best regards
 
Sten Carlsen
 
No improvements come from shouting:
 
       "MALE BOVINE MANURE!!!"=
--_000_90903C21C73202418A48BFBE80AEE5EB22EFC062xmbalnx06ciscoc_-- From Ted.Lemon@nominum.com Wed Apr 17 20:01:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11D721E80B9 for ; Wed, 17 Apr 2013 20:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, 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 DIZv3PgmFXjt for ; Wed, 17 Apr 2013 20:01:20 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 41A7921E8095 for ; Wed, 17 Apr 2013 20:01:20 -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 DSNKUW9h/2hoAufepKO2Kz3Rjyqx6kUud0/H@postini.com; Wed, 17 Apr 2013 20:01:20 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 B39761B8115 for ; Wed, 17 Apr 2013 20:01:19 -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 A5E06190061; Wed, 17 Apr 2013 20:01:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 20:01:14 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 Thread-Index: AQHOO3UeFxdaVYufjUW70j+3IavbE5jbs+8AgAAMd4A= Date: Thu, 18 Apr 2013 03:01:13 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077514E760@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> <516EACE7.1080800@s-carlsen.dk> <90903C21C73202418A48BFBE80AEE5EB22EFC062@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB22EFC062@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B63077514E760mbx01winnominum_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 03:01:21 -0000 --_000_8D23D4052ABE7A4490E77B1A012B63077514E760mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 17, 2013, at 10:16 PM, Gaurav Halwasia (ghalwasi) > wrote: Why the Intended status of this document is Standards Track instead of Info= rmational ? I fixed that in the -01 draft; that's the only change, actually. --_000_8D23D4052ABE7A4490E77B1A012B63077514E760mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <61EE467FF7EA5A4587546DC424C76458@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 17, 2013, at 10:16 PM, Gaurav Halwasia (ghalwasi) <ghalwasi@cisco.com> wrote:
Why the Intended s=
tatus of this document is Standards Track instead of Informational ?=

I fixed that in the -01 draft; that's the only change, actually.

--_000_8D23D4052ABE7A4490E77B1A012B63077514E760mbx01winnominum_-- From ghalwasi@cisco.com Wed Apr 17 20:06:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3F21E80F7 for ; Wed, 17 Apr 2013 20:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRFaT9rN6O2Z for ; Wed, 17 Apr 2013 20:06:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4D21E80ED for ; Wed, 17 Apr 2013 20:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2842; q=dns/txt; s=iport; t=1366254380; x=1367463980; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eiyBi38GNZLi3sUfP7x0K7ivfvAxyUp6RPlmJNJRcgI=; b=lvro6Z0t+vrjPYZhL43ujUgnT6rg4A63jSIVLPzT6QOkGcFPNNvB//ZS SFLOaZyqGG+FvDJSgxjudq4qg4zevXhSUhEgtsexAAyYO9W1sEeI9HyeL v0h3kBt6lPPYDx1Sp2ZrxIgjrSr2EJ2dopNHYOuJYUp0F/pMRbtSYH1gJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQaALBib1GtJXHA/2dsb2JhbABQgW8GAUxENsBYgQEWdIIgAQEELUwQAgEIBB4kMiUCBA4NiAy9a45pMQeCZWEDqBqDC4Io X-IronPort-AV: E=Sophos;i="4.87,498,1363132800"; d="scan'208,217";a="200148725" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 18 Apr 2013 03:06:20 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3I36JSd022053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 03:06:19 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 22:06:19 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon Thread-Topic: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 Thread-Index: AQHOO3UeqmSrLUEdTk6bqfL4JuIH3ZjbPXWQgABhaoD//62GgA== Date: Thu, 18 Apr 2013 03:06:18 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22EFC488@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> <516EACE7.1080800@s-carlsen.dk> <90903C21C73202418A48BFBE80AEE5EB22EFC062@xmb-aln-x06.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077514E760@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514E760@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.54] Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB22EFC488xmbalnx06ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 03:06:21 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB22EFC488xmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >I fixed that in the -01 draft; that's the only change, actually. Ok, thanks! --_000_90903C21C73202418A48BFBE80AEE5EB22EFC488xmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>I fixed tha= t in the -01 draft; that's the only change, actually.

 

Ok, thanks!

--_000_90903C21C73202418A48BFBE80AEE5EB22EFC488xmbalnx06ciscoc_-- From ghalwasi@cisco.com Wed Apr 17 20:40:33 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77CD21E80BE for ; Wed, 17 Apr 2013 20:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 l2MRFVfVt3EV for ; Wed, 17 Apr 2013 20:40:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D041B21E80F3 for ; Wed, 17 Apr 2013 20:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6195; q=dns/txt; s=iport; t=1366256431; x=1367466031; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=q6daiU/Shi8owfOR4rmjAoflxGEX5xhFlXs3jQj9yrw=; b=ffxgnj3/rjU6/zvG2yyO4DU4jN384SAUWezD4My+F2FNt+k84mfX31Cw XJyoo8HitZKywQvclL8EX/2uQWadB4q1AjeMn3hrtNQAwEcKZB/T+JFg0 42KMT07uXsmJlEGHrzg39G1eHANLVnIhAeC4HyUNexOQ64QwgpCFaplee 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAMRqb1GtJV2Z/2dsb2JhbABQgkJENrgeAYg5gQEWdIIfAQEBBB0QXAIBCBEEAQELHQcyFAkIAQEEARIIiAwMvVKNaIEBJhEBgmVhA5gpj3GBVYE2gXM1 X-IronPort-AV: E=Sophos;i="4.87,498,1363132800"; d="scan'208,217";a="197095841" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 18 Apr 2013 03:40:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3I3eVEO008293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Apr 2013 03:40:31 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 22:40:30 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 Thread-Index: Ac47b6ONLSN8YQAvTLWyulsavR6P7gAdq2jA Date: Thu, 18 Apr 2013 03:40:29 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22EFC57D@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.54] Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB22EFC57Dxmbalnx06ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 03:40:33 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB22EFC57Dxmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read/reviewed this document earlier and I do support this document to get= adopted as WG document. -Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, April 17, 2013 7:03 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-ident= ifier-04 - Ends May 2, 2013 Hi all: The authors have requested a call for adoption by the WG for draft-bhandari= -dhc-access-network-identifier-04. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that the 04 draft was just published and has redesigned options to bet= ter follow the option guidelines. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-bhandari-dhc-access-network-identifier-04. Regards, Tomek & Bernie --_000_90903C21C73202418A48BFBE80AEE5EB22EFC57Dxmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read/reviewed this d= ocument earlier and I do support this document to get adopted as WG documen= t.

 

-Gaurav

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 7:03 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-networ= k-identifier-04 - Ends May 2, 2013

 

Hi all:

 

The authors have requested a call for adoption by= the WG for draft-bhandari-dhc-access-network-identifier-04.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that the 04 draft was just published and has= redesigned options to better follow the option guidelines.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04<= /a>.

 

Regards,

Tomek & Bernie

 

--_000_90903C21C73202418A48BFBE80AEE5EB22EFC57Dxmbalnx06ciscoc_-- From jouni.nospam@gmail.com Wed Apr 17 23:17:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387A621F8F22 for ; Wed, 17 Apr 2013 23:17:01 -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 BKkaceduKjIX for ; Wed, 17 Apr 2013 23:16:59 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id D66D921F8F1A for ; Wed, 17 Apr 2013 23:16:58 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id x11so2356858lbi.1 for ; Wed, 17 Apr 2013 23:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=B757w0Y+jYyjql7KlvdjBIxlVlIWW2rM5dGtdEGhsD0=; b=JIEe2DOJ174p8u6e149Cs4wKHxXiU35Vb92l9tJorMiwT6ciPfJ/ETKwL+xdzQ9mvY jFQpdUyhRf7BoaxJwW9ii5+OhaciSTAlC/Q17Mur7rZu+plVKJWoJozr9N5/bpUrremp esmGOFB2jtBix9Yymh8Yq0hrPepoQgxya1F4Wm0PcwbHUga1+NbZhIRRO0/QVJtT8qWA nH8N2xfV97UEDTBpyX0AB1eWjAZm7C9LMkPiz7G+HZW/6dr8nPW4fmA2HpYTl7nnfedU iYgvOh/B+hUCYan2IzV3dVV3rPmmMH/n/zyZnFL8a9onYBqOnASggsuwkvoVQB/EolAK UX2Q== X-Received: by 10.112.150.34 with SMTP id uf2mr5158901lbb.1.1366265817750; Wed, 17 Apr 2013 23:16:57 -0700 (PDT) Received: from [192.168.250.209] ([194.100.71.98]) by mx.google.com with ESMTPS id t6sm3753356lae.3.2013.04.17.23.16.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 23:16:56 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 18 Apr 2013 09:16:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <09F34B71-C08D-4BE6-9519-C5BB953B5703@gmail.com> References: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1503) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 06:17:01 -0000 On Apr 18, 2013, at 12:22 AM, Behcet Sarikaya = wrote: > Hi Sri, >=20 > I think that Client/Server behaviour (Section 7 & 9) in the draft = needs some clarification. I could agree on that. The current text is 'slightly' thin ;-) - Jouni >=20 > Please check Bernie's mail: > http://www.ietf.org/mail-archive/web/dhcwg/current/msg11144.html > on draft-ietf-dhc-80211-option-01.txt. >=20 > Also please check the operation described in Li's draft: > http://tools.ietf.org/html/draft-xue-dhc-location-option-01 >=20 > Regards, >=20 > Behcet > On Wed, Apr 17, 2013 at 10:47 AM, Sri Gundavelli (sgundave) = wrote: > Hi Ted, >=20 > Thanks for your comments. >=20 > This requirement is not coming from any SDO. We believe this is a = generic > requirement for IETF based IP architectures. >=20 > As you are aware, many operators are deploying large scale SP WiFI > networks. These deployments are based on standard IETF protocols and > architectures (tunneling, mobility, Routing, AAA protocols ...). In = many > of these deployments the subscriber services are tied to the access > network, for example, the initial portal page may be different based = on > the user location (SSID, AP Mac address ..). These parameters are > typically carried on DHCP option-82, and are coded in a vendor basis. > There is no standard encoding that a backend system can reliably = depend on > for learning these parameters. In the past when WiFI was largely = contained > to enterprises, with single vendor solutions, this worked fine. But, = now > in many deployments there are multi-vendor systems and interop is > required. The draft is trying to attempt to fix that gap. We want to = drive > this work in DHC, not using a liaison statement, but as a gap in IETF > protocols, to solve a practical deployment issue and improve > interoperability. >=20 > I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI > networks and he can comment on this. >=20 >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 4/17/13 7:59 AM, "Ted Lemon" wrote: >=20 > >When we talked about this earlier, I said that it might be better to = have > >this work done in DHC rather than forcing it to find a new working = group > >because it seemed to be something that was being asked for by other = SDOs. > > However, the authors never said anything about that over and above = what > >they've already said in meetings, so I don't actually have a clear > >picture of who is asking for this. Looking in the data tracker, I = don't > >find any liaison statement requesting that this work be done. > > > >The authors have expressed a great deal of urgency about this work, = and I > >don't want to delay it any further, so I will state that as a > >participant, I'm in favor of the working group taking on the work. > >However, with my AD hat on, I would like to get some kind of actual > >request for help from the SDOs who want this functionality before the = end > >of the call for adoption. Otherwise I think Bernie's concern that = the > >DHC working group really isn't qualified to evaluate the validity of = the > >option contents will remain unaddressed, and I think it's a valid = concern. > > > >The request from the SDOs should be of the form "we need DHCP options = to > >deliver the following bits of functionality," and should briefly = describe > >the functionality that's needed, and refer to the documents that the = SDO > >is working on that support this need. > > > >If this need is not really coming from these SDOs, but rather from = some > >IETF working group, then perhaps Bernie's original observation was > >correct, and this work should be done in that working group instead. > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jouni.nospam@gmail.com Thu Apr 18 00:06:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADBC21F8F58 for ; Thu, 18 Apr 2013 00:06:03 -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 PLPy0VbEoFLk for ; Thu, 18 Apr 2013 00:06:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17B9521F8F4E for ; Thu, 18 Apr 2013 00:06:01 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so2382808lbi.3 for ; Thu, 18 Apr 2013 00:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=vSHN+HoEhFlieMZmis14gyrLSzQCeZwDRQRFFGFkPFU=; b=O3s2EzHMLUzH67V7W5/B6uCteTbPssEr5SZzZDF2SWVFQpFyWncqGHgxbP52Zw7G7R jsjPm5ToXG+zyUGzgtGNfynXctqVqB2rgFSbankRpTH/Ec8di7gI5dIBvJb7GdBkvJbe afCbqrO+fz2ayxfpZ3wsIoo9aRGoHLiubFih9hmJoGqaEt46IlqQfA4rfHQ3uggZpMFt oN8D6eIDxXUPYDF9cbJI/663zg7TaGmZCQ9fvrJSfdN34Bu90MybY3hDFvUyRd4ff4qQ 5/83uqbdCWk+BeRTx34lERYjblqCF72xJS4BcUrTxktIuHoc5sCfWPrnKHU8TOCQopqu ciyQ== X-Received: by 10.112.154.170 with SMTP id vp10mr5103668lbb.10.1366268761066; Thu, 18 Apr 2013 00:06:01 -0700 (PDT) Received: from [192.168.250.209] ([194.100.71.98]) by mx.google.com with ESMTPS id a9sm3821052laf.2.2013.04.18.00.05.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 00:06:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> Date: Thu, 18 Apr 2013 10:06:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <65C5E25E-7019-4D0B-B127-C5ED99E59569@gmail.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:06:03 -0000 Ted, On Apr 17, 2013, at 5:59 PM, Ted Lemon wrote: > When we talked about this earlier, I said that it might be better to = have this work done in DHC rather than forcing it to find a new working = group because it seemed to be something that was being asked for by = other SDOs. However, the authors never said anything about that over = and above what they've already said in meetings, so I don't actually = have a clear picture of who is asking for this. Looking in the data = tracker, I don't find any liaison statement requesting that this work be = done. Echoing what Sri already said. We are not directly tasked by other SDOs. There are activities in other SDOs that are parallel (but not orthogonal) to this and they can use or choose not to use the IETF solutions. Nevertheless, we need the DHCP protocol support to complete what has already been done e.g. in RFC6757. > The authors have expressed a great deal of urgency about this work, = and I don't want to delay it any further, so I will state that as a = participant, I'm in favor of the working group taking on the work. = However, with my AD hat on, I would like to get some kind of actual = request for help from the SDOs who want this functionality before the = end of the call for adoption. Otherwise I think Bernie's concern that = the DHC working group really isn't qualified to evaluate the validity of = the option contents will remain unaddressed, and I think it's a valid = concern. I would say we have the required skillset in the room to evaluate the DHCP option content validity. Actually, as=20 long as it complies with RFC6757, we are mostly fine. I find quite a bit similarities between this work and=20 RFC6603. The work was done entirely in IETF and one (but not the only) of the driving use cases was indeed deployment in other SDO defined network architecture. RFC6603 was later adopted as a solution by the "other" SDO once IETF had done its work. Same could happen here but there is no guarantees. Even in the latter case, the protocol extension is usable in vendor products. > The request from the SDOs should be of the form "we need DHCP options = to deliver the following bits of functionality," and should briefly = describe the functionality that's needed, and refer to the documents = that the SDO is working on that support this need. >=20 > If this need is not really coming from these SDOs, but rather from = some IETF working group, then perhaps Bernie's original observation was = correct, and this work should be done in that working group instead. Going to Netext is not, imho, desirable. There is nothing specific to do on the PMIP6 side anymore. This is purely about DHCP and the expertise is supposed to be in DHC WG, right? - Jouni >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Thu Apr 18 07:59:12 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3325D21F8F03 for ; Thu, 18 Apr 2013 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=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 Z6+ZgTdg7cZi for ; Thu, 18 Apr 2013 07:59:11 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id A685D21F8EF5 for ; Thu, 18 Apr 2013 07:59:11 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so1666788pad.16 for ; Thu, 18 Apr 2013 07:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=t5QXzHZEBNsS1hRs54kaQMzmQ2POO8KswUYQNCQyYL4=; b=QMrRsl3lxW9WCHapadn4kTlMSONbjZOpp5hj8r6rIixbl0+E5OX227EuoE+YddNCzK 9q1GhnLuzEMQyhmE/fN3NPYOumK7v5Lr6Zh9SLaHvuwQeN4ziGD/JQzDiYi/XryaQQrP EFDnb+ZIMYOiuQSKzVGhyU26W2m6O916xwOyOa/t2XUGqQmtF4GkEh2LkYfotvG0zizp mOIOyqFzxgo/Ft/wa6D6lcoTGiN+VDkhJTDLb4liKNhUhbW5T2R4KURkcteiQFMBV506 Xp3gxMVrSStPH6tcIbNuuXpAJ6VARhmhdCS1n2P8W/LVqA3s0d0CBUjpTZt4NtoG9+vu U9Cw== X-Received: by 10.68.172.65 with SMTP id ba1mr14179077pbc.166.1366297151496; Thu, 18 Apr 2013 07:59:11 -0700 (PDT) Received: from thomson-osx.lan (dsl092-002-166.sfo1.dsl.speakeasy.net. [66.92.2.166]) by mx.google.com with ESMTPS id zv4sm10150759pbb.28.2013.04.18.07.59.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 07:59:10 -0700 (PDT) Message-ID: <51700A3E.10809@gmail.com> Date: Thu, 18 Apr 2013 07:59:10 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077514CF20@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077514CF20@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 14:59:12 -0000 On 13-04-17 06:02, Ted Lemon wrote: > I also support adoption. I also support adoption. Tomek From tomasz.mrugalski@gmail.com Thu Apr 18 08:07:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1885521F8EED for ; Thu, 18 Apr 2013 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-2.407, BAYES_00=-2.599, HELO_LH_HOME=3.714, J_CHICKENPOX_31=0.6, RDNS_DYNAMIC=0.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 7CotLIwxhpJz for ; Thu, 18 Apr 2013 08:07:10 -0700 (PDT) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9E32D21F8EBF for ; Thu, 18 Apr 2013 08:07:10 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id z20so1434016dae.3 for ; Thu, 18 Apr 2013 08:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=APmu+wPpKvr+EbXPlVDpZ7zcAlorJ07SO/F7pDEF4nA=; b=abW2nDi9xSd9uz+nUTw42wjhwHdKzTsW8BNadDu4rI1HlWVvZ21otwCHRs20h8Kmhs ZyD9KP8svSPmBXw9nyg/diB7eKTjAufOG0b4BT8V+O7gRO+6vAd+b6/X8MGYOoW7jA3F ZXiN3fOb3v579fa5MZy+1j09JWeXEPv9fN2KJzbNh1juo+Urk8BwnvF4vDWi05GO2Xge cZSAR5zksGQ4UfOpNMzRfh/EXU6vPwO3Y5TOvsTsnb5U/i3jw8BOuwQK8s4g52Xo2pHT 849L9vvElHcphqX6Fl6oay0vdRvgcEvr84kT8cxeKZaTGvWHKNrY/wuINFLl+4H5cTVl ctlw== X-Received: by 10.68.170.99 with SMTP id al3mr1324976pbc.201.1366297630417; Thu, 18 Apr 2013 08:07:10 -0700 (PDT) Received: from thomson-osx.lan (dsl092-002-166.sfo1.dsl.speakeasy.net. [66.92.2.166]) by mx.google.com with ESMTPS id ms9sm10187675pbc.20.2013.04.18.08.07.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 08:07:09 -0700 (PDT) Message-ID: <51700C15.4020209@gmail.com> Date: Thu, 18 Apr 2013 08:07:01 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E184D2C7A@xmb-rcd-x04.cisco.com> <5162F5DB.7010404@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AA19456@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B63077514CF53@mbx-01.win.nominum.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 15:07:11 -0000 On 13-04-17 09:18, Andre Kostur wrote: > I support adoption. I also support this work. It is short, but very useful clarification. It will make any future extensions easier to deploy. From sarikaya2012@gmail.com Thu Apr 18 11:31:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4021F9356 for ; Thu, 18 Apr 2013 11:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 52duIeqp+zMV for ; Thu, 18 Apr 2013 11:30:59 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 60C7C21F9310 for ; Thu, 18 Apr 2013 11:30:59 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so3009252lbi.11 for ; Thu, 18 Apr 2013 11:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M81mwJdrH6w4A5rlIcAa+4TVM+Zr69CKjgVjZ/XCjFc=; b=cQhvG6hZiGay793gbDMSn//p5VvqKiH0GqDSb0GZCPr/XdEhLD171sNYnMD4JYpf/L izHCJWuiNMbo6PXhoQyyt4lJ0cBjufE0aaq7RJC3ONyXfT9OMqIMXV+2TOtZttVynnAg cgBiJkgfwlBD/vKWhRkflyVsGNVHL4p106kCt5RrEYazu/cmCz7DcIKcVDO38mluZoVJ tq+94aHe7FmISdXsS8rufb342G4joEzjAY8+x55f4V5EB0WIH/AoNMn7WgviPhifLE+T GAuAUmfz+fV3emmpgh6Xtur+Fl8Ntq8vGwc433TkwCcnLo4lWj4Di72gioGhRZmn8EB2 +djg== MIME-Version: 1.0 X-Received: by 10.152.2.102 with SMTP id 6mr6388576lat.23.1366309858297; Thu, 18 Apr 2013 11:30:58 -0700 (PDT) Received: by 10.114.175.140 with HTTP; Thu, 18 Apr 2013 11:30:58 -0700 (PDT) In-Reply-To: <65C5E25E-7019-4D0B-B127-C5ED99E59569@gmail.com> References: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <65C5E25E-7019-4D0B-B127-C5ED99E59569@gmail.com> Date: Thu, 18 Apr 2013 13:30:58 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=089e013c6b88c1cfc304daa6cd44 Cc: "dhcwg@ietf.org" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 18:31:00 -0000 --089e013c6b88c1cfc304daa6cd44 Content-Type: text/plain; charset=ISO-8859-1 I agree that Netext is not the right place. It could be fmc. I can say that 3GPP will not support because they don't use DHCPv6. BBF in the context of fmc follows 3GPP. Maybe IEEE 802.11? Regards, Behcet On Thu, Apr 18, 2013 at 2:06 AM, Jouni Korhonen wrote: > > Ted, > > On Apr 17, 2013, at 5:59 PM, Ted Lemon wrote: > > > When we talked about this earlier, I said that it might be better to > have this work done in DHC rather than forcing it to find a new working > group because it seemed to be something that was being asked for by other > SDOs. However, the authors never said anything about that over and above > what they've already said in meetings, so I don't actually have a clear > picture of who is asking for this. Looking in the data tracker, I don't > find any liaison statement requesting that this work be done. > > Echoing what Sri already said. We are not directly tasked by > other SDOs. There are activities in other SDOs that are > parallel (but not orthogonal) to this and they can use or > choose not to use the IETF solutions. Nevertheless, we need > the DHCP protocol support to complete what has already been > done e.g. in RFC6757. > > > The authors have expressed a great deal of urgency about this work, and > I don't want to delay it any further, so I will state that as a > participant, I'm in favor of the working group taking on the work. > However, with my AD hat on, I would like to get some kind of actual request > for help from the SDOs who want this functionality before the end of the > call for adoption. Otherwise I think Bernie's concern that the DHC > working group really isn't qualified to evaluate the validity of the option > contents will remain unaddressed, and I think it's a valid concern. > > I would say we have the required skillset in the room to > evaluate the DHCP option content validity. Actually, as > long as it complies with RFC6757, we are mostly fine. > > I find quite a bit similarities between this work and > RFC6603. The work was done entirely in IETF and one (but > not the only) of the driving use cases was indeed deployment > in other SDO defined network architecture. RFC6603 was > later adopted as a solution by the "other" SDO once IETF > had done its work. Same could happen here but there is > no guarantees. Even in the latter case, the protocol > extension is usable in vendor products. > > > The request from the SDOs should be of the form "we need DHCP options to > deliver the following bits of functionality," and should briefly describe > the functionality that's needed, and refer to the documents that the SDO is > working on that support this need. > > > > If this need is not really coming from these SDOs, but rather from some > IETF working group, then perhaps Bernie's original observation was correct, > and this work should be done in that working group instead. > > Going to Netext is not, imho, desirable. There is nothing > specific to do on the PMIP6 side anymore. This is purely > about DHCP and the expertise is supposed to be in DHC WG, > right? > > - Jouni > > > > > > > _______________________________________________ > > 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 > --089e013c6b88c1cfc304daa6cd44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that Netext is not the right place.
It could be fmc.

I c= an say that 3GPP will not support because they don't use DHCPv6.
BBF in the context of fmc follows 3GPP.

Maybe IEEE 802.11?

Regards,

Behcet

On Thu, Apr 18, 20= 13 at 2:06 AM, Jouni Korhonen <jouni.nospam@gmail.com> = wrote:

Ted,

On Apr 17, 2013, at 5:59 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> When we talked about this earlier, I said that it might be better to h= ave this work done in DHC rather than forcing it to find a new working grou= p because it seemed to be something that was being asked for by other SDOs.= =A0 However, the authors never said anything about that over and above wha= t they've already said in meetings, so I don't actually have a clea= r picture of who is asking for this. =A0 Looking in the data tracker, I don= 't find any liaison statement requesting that this work be done.

Echoing what Sri already said. We are not directly tasked by
other SDOs. There are activities in other SDOs that are
parallel (but not orthogonal) to this and they can use or
choose not to use the IETF solutions. Nevertheless, we need
the DHCP protocol support to complete what has already been
done e.g. in RFC6757.

> The authors have expressed a great deal of urgency about this work, an= d I don't want to delay it any further, so I will state that as a parti= cipant, I'm in favor of the working group taking on the work. =A0 Howev= er, with my AD hat on, I would like to get some kind of actual request for = help from the SDOs who want this functionality before the end of the call f= or adoption. =A0 Otherwise I think Bernie's concern that the DHC workin= g group really isn't qualified to evaluate the validity of the option c= ontents will remain unaddressed, and I think it's a valid concern.

I would say we have the required skillset in the room to
evaluate the DHCP option content validity. Actually, as
long as it complies with RFC6757, we are mostly fine.

I find quite a bit similarities between this work and
RFC6603. The work was done entirely in IETF and one (but
not the only) of the driving use cases was indeed deployment
in other SDO defined network architecture. RFC6603 was
later adopted as a solution by the "other" SDO once IETF
had done its work. Same could happen here but there is
no guarantees. Even in the latter case, the protocol
extension is usable in vendor products.

> The request from the SDOs should be of the form "we need DHCP opt= ions to deliver the following bits of functionality," and should brief= ly describe the functionality that's needed, and refer to the documents= that the SDO is working on that support this need.
>
> If this need is not really coming from these SDOs, but rather from som= e IETF working group, then perhaps Bernie's original observation was co= rrect, and this work should be done in that working group instead.

Going to Netext is not, imho, desirable. There is nothing
specific to do on the PMIP6 side anymore. This is purely
about DHCP and the expertise is supposed to be in DHC WG,
right?

- Jouni



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

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

--089e013c6b88c1cfc304daa6cd44-- From leaf.yeh.sdo@gmail.com Thu Apr 18 20:20:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4236E1F0D11 for ; Thu, 18 Apr 2013 20:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.371 X-Spam-Level: *** X-Spam-Status: No, score=3.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 zDAfGHJ67J5c for ; Thu, 18 Apr 2013 20:20:47 -0700 (PDT) Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5069221E803A for ; Thu, 18 Apr 2013 20:20:46 -0700 (PDT) Received: by mail-da0-f50.google.com with SMTP id a4so220575dad.37 for ; Thu, 18 Apr 2013 20:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=gv7LDJ93b1K9xXKXYKh/KZE5Ri9wn8B/+l6513WipYY=; b=k2fvJXsN5v7A2wo7LnKesJ43KoyoHuMM7AxSPp7h7/DIKDl48Pd9DXlz7RvrabpEky DkRU4xCuNWNU3AMpDViauV92KR+6HtOWnpliQmeai2KkXbYn/jFRqdeofz67WD010GHe vjlq7JrwnRWEPiFRuhmwY8ivKIwKTR4t7uaxqCkbHXTHk/H3a1/AVxnLMJfD4i1EH177 mLkJJBnDFF5Yf/5jHzxHUHOTpEBhNRdiNGhL3MXJ/4B3ajJc2JXN6YXq4febwmc6AjO0 p7hhNWVxrPexGTEEBFZeDdTcEWU1cF3ODigCnhuwZFTJhS0JSdl14x07HESlNLpT9NnJ ArKw== X-Received: by 10.66.181.208 with SMTP id dy16mr15905679pac.5.1366341645955; Thu, 18 Apr 2013 20:20:45 -0700 (PDT) Received: from PC ([61.48.185.127]) by mx.google.com with ESMTPS id j13sm12975286pat.17.2013.04.18.20.20.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 20:20:45 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com> In-Reply-To: <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com> Date: Fri, 19 Apr 2013 11:20:38 +0800 Message-ID: <5170b80d.0d43420a.09e7.ffffd707@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac45Cz/py3/bdmb7QvCqM9bmbO85vQBX/aqAAD2RoOQAIbb+AA== Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:20:48 -0000 BV> The interface id option can not be used to identify the relay. There is no requirement that the interface id is globally unique - it only has significance to the relay itself. If we decide to come back & comply with the exact language of IETF defined before, how about to update the text in section 5 to be "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, 53) or Interface ID option (OPTION_INTERFACE_ID, 18) so that the server can identify the relay agent itself or its particular customer-facing interface with which the prefix pool is associated, if the server can not use the link-address field specified in the encapsulation of the DHCPv6 RELAY-FORW message to identify the interface of the link on which the clients are located." and the text in section 6 to be "The server MAY use the link-address specified in RELAY-FORW message to identify the relay agent itself and its particular customer-facing interface where the prefix pool is associated, but the server has to maintain the binding data of prefix pools in association with these link-addresses. To be more readable, the server can alternatively use Relay-ID and Interface-ID option included in the RELAY-FORW message by the relay agent to identify the relay agent itself and its particular customer-facing interface where the prefix pool is associated. In order to give a meaningful reply, the server has to maintain the binding data of prefix pools in association with these Relay-ID and Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD copy the Interface-ID option from the RELAY-FORW message into the RELAY-REPL message." Does the server need to copy Relay-ID from the RELAY-FORW into the RELAY-REPL? Best Regards, Leaf PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Wednesday, April 17, 2013 7:49 PM To: Leaf Yeh Cc: Tomek Mrugalski; dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Fyi - > To be more readable, the server can alternatively > use the Interface ID option included in the RELAY-FORW message by the > relay agent to identify the relay agent itself The interface id option can not be used to identify the relay. There is no requirement that the interface id is globally unique - it only has significance to the relay itself. - Bernie On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" wrote: > Tomek - How about "Misconfigured or compromised DHCPv6 server can > cause relays to start announcing arbitrary prefixes, including default > routes, which could lead to traffic hijack."? > > I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't > bought in the part of 'Compromised DHCPv6 server'. I don't believe the > ORO option included by the relay could compromise the DHCPv6 server. Right? > > >> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >> "The relay agent SHOULD include the Interface ID option")... > > Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: > "The server MAY use the link-address specified in RELAY-FORW message > to identify the relay agent itself or its particular customer-facing > interface where the prefix pool is associated, but the server has to > maintain the binding data of prefix pools in association with these > link-addresses. To be more readable, the server can alternatively > use the Interface ID option included in the RELAY-FORW message by the > relay agent to identify the relay agent itself or its particular > customer-facing interface where the prefix pool is associated. In > order to give a meaningful reply, the server has to maintain the > binding data of prefix pools in association with the information > derived from the Interface ID option." > The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both > use cases shown in section 3. > > > Tomek -RFC3315: relay MUST include interface-id if the link-address in > server's response is not sufficient to select downlink interface. > prefix-pool-opt-02: relay SHOULD include interface-id, so the the > server can identify the relay itself > (tomek: that's wrong. Interface-id is for interface or subnet > identification, not relay identification. Relay-id is used for that > purpose, see RFC5460, section 5.4.1) > > There might be a small debate here. The question could be whether the > server could identify the relay after receiving the interface-id of > it. I guess our smart server already support that in the real > deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 > (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: > The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be > able to use Option 18 in order to retrieve the Access Node identifier > and access this table in order to identify the ad-hoc pool of prefixes > or addresses.] > > OTOH, I believe relay-id defined in RFC5460 can also be used in the > case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. > 2); though if the mechanism of Bulk-Lease-Query is employed, the relay > also need to include OPTION_ RELAY_ID in the relay-forward message for > the basic operation of DHCPv6 prefix or address assignment. > > > Tomek - ... if the server would not like to use the link-address field > specified in RELAY-FORW message > (tomek: that imprecise or wrong. The server is not at liberty to "not > use link-address field". There's a specific algorithm defined in > section 11 of > RFC3315 that the server must follow it). > > Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, > has the following text: > " A server selects addresses to be assigned to an IA according to the > address assignment policies determined by the server administrator > and the specific information the server determines about the client > from some combination of the following sources: > - The link to which the client is attached. ... If the server > receives the message from a forwarding relay > agent, then the client is on the same link as the one to which > the interface, identified by the link-address field in the > message from the relay agent, is attached... > - The DUID supplied by the client. > - Other information in options supplied by the client. > - Other information in options supplied by the relay agent." > The above text sounds not put link-address ahead of options supplied > by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF > TR-177, its R-07, > R-08 & section6.6 (...In some deployments there is neither a need nor > a desire to configure a global or unique local address to the > interface on which the client messages are received. Such a deployment > does not allow the BNG to insert an IPv6 address in the link-address > field...).] > > > Best Regards, > Leaf > > > > -----Original Message----- > From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] > Sent: Sunday, April 14, 2013 8:26 PM > To: Leaf Yeh > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - > Respond by April 8, 2013 > > On 13-04-12 03:15, Leaf Yeh wrote: >> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? >> Your relay will hijack the whole network? ... >> >> The relay's behavior is still under control by the server. If it got >> the wrong configuration, the server could also send out ::/0 in the >> IA_PD. So this may sound an administration error. We just want the >> prefix pools not configure to be ::/0 or any overlap between them. I >> feel a little stuck on the exact text you want. How about 'The >> administrator of the DHCPv6 server should pay more attention to the >> configuration of the prefix pools, for examples, a. ::/0 may cause a >> big routing problem in the whole ISP network; b. the configuration of >> prefix pool should avoid overlap in the address plan, and etc.' ? I >> am > not quite sure... > Administrator mistake is one concern, the other one is that DHCPv6 > server may become an attractive attack target when prefix-pool is deployed. > > How about "Misconfigured or compromised DHCPv6 server can cause relays > to start announcing arbitrary prefixes, including default routes, > which could lead to traffic hijack."? > >> Tomek - Bernie had this concern and I tend to agree with him... the >> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my >> reply to Bernie's email. Thanks for your suggestion here. Do we need >> more explanation on the mathematic function of floor() ? :-) > I don't think so. A potential implementor who doesn't know what > floor() function does should probably consider starting a career in > some other industry. :-) > >> Tomek - ...(I know that requestor in most cases is part of a relay, >> but from protocol perspective these are separate entities)...Yes. >> Please split actions taken by requestor into separate section. It can >> be subsection 5.1 if you like to. >> >> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the >> section 5 "Relay Agent Behavior" (just for an editorial change)? Do >> you want section >> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? > Yes to both. > >> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >> "The relay agent SHOULD include the Interface ID option")... >> >> After searching and reading, I still can't find this sentence in RFC3315. > It is in prefix-pool-opt-02, section 5, second paragraph. Text from > prefix-pool-opt-02 is an imprecise subset of behaviour described in > RFC3315, section 20.1.1, second paragraph. Here's the difference: > > RFC3315: relay MUST include interface-id if the link-address in > server's response is not sufficient to select downlink interface. > > prefix-pool-opt-02: relay SHOULD include interface-id, so the the > server can identify the relay itself (tomek: that's wrong. > Interface-id is for interface or subnet identification, not relay > identification. Relay-id is used for that purpose, see RFC5460, > section 5.4.1) if the server would not like to use the link-address field specified in RELAY-FORW message (tomek: > that imprecise or wrong. The server is not at liberty to "not use > link-address field". There's a specific algorithm defined in section > 11 of > RFC3315 that the server must follow it). > > Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Apr 18 20:27:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1941121E803C for ; Thu, 18 Apr 2013 20:27:32 -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 M3V7aiXNlurn for ; Thu, 18 Apr 2013 20:27:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E24D021F93AB for ; Thu, 18 Apr 2013 20:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60950; q=dns/txt; s=iport; t=1366342045; x=1367551645; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eSmXQdScR4CJRpdKa13l8c6wYhN/dQq6FdlDpiimkfE=; b=mncTdNq+Nx3LeECzg9n5E2wnLDQaHwaLhHzIZpbumnw9LPWdiuCYgFzk 9uOF6WfXzpeW4BHm/trObTYQzch+wnGZAzgczZsBVvBOKlI1eKHP8J/v6 3Zebwc2ES4yJHB+BGWkZjS3cPBeZE0fInqY24iiyX9lJ5ohOfKsX+T/qo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FADK5cFGtJV2Z/2dsb2JhbAA2EAqCQkQ2wGOBBxZ0gh8BAQEDAQEBARcTQQsFBwQCAQgRBAEBCxYBBgchBgsUCQgBAQQOBQgTh2cDCQYML7QJDYldjEWBEQaBCyYGAQQGAQaCYGEDkzqBao1VBoUcgVWBNoFzNQ X-IronPort-AV: E=Sophos;i="4.87,505,1363132800"; d="scan'208,217";a="200523408" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 19 Apr 2013 03:27:23 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3J3RNHu026934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 03:27:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 22:27:23 -0500 From: "Bernie Volz (volz)" To: Leaf Yeh Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: Ac45Cz/py3/bdmb7QvCqM9bmbO85vQBX/aqAAD2RoOQAAg7x0ABQ5esQ Date: Fri, 19 Apr 2013 03:27:22 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850E7D3@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com> <5170b87e.8abd440a.4b9d.ffffb77a@mx.google.com> In-Reply-To: <5170b87e.8abd440a.4b9d.ffffb77a@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1850E7D3xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 18 Apr 2013 20:28:07 -0700 Cc: "dhcwg@ietf.org" , 'Ted Lemon' Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:27:32 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1850E7D3xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, that wasn't a requirement in RFC 3315 so if this draft assumes that it = is (based on other standards), that needs to be clarified in the document -= that it requires the Interface-ID is sufficiently unique (as per [referenc= es]). - Bernie From: Leaf Yeh [mailto:leaf.yeh.sdo@gmail.com] Sent: Thursday, April 18, 2013 11:22 PM To: Bernie Volz (volz) Cc: 'Tomek Mrugalski'; 'Ted Lemon' Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Resp= ond by April 8, 2013 BV> The interface id option can not be used to identify the relay. There is= no requirement that the interface id is globally unique - it only has sign= ificance to the relay itself. The documents of BBF TR-177 & TR-101 has different idea & requirements on t= he usage of Interface-ID. TR-177 R-07 "The Access Node MUST, when performing the function of an LDRA, be able to encode the access loop identification in the Interface-Id Option (option 18= , defined in RFC 3315 [14]) and add the option to the DHCPv6 Relay-forward messages sent= to the BNG, which acts as a DHCPv6 server or a DHCPv6 Relay Agent." Note: LDRA is the RA defined in RFC6221. TR-177 R-08 "When adding the Interface-Id, the encoding MUST uniquely identify the Acce= ss Node and the access loop logical port on the Access Node on which the DHCPv= 6 message was received. The Interface-Id contains a locally administered ASCI= I string generated by the Access Node, representing the corresponding access loop lo= gical port (U interface). The actual syntax of the access loop identification in = the Interface- Id is identical to the syntax defined in Section 3.9.3/TR-101 and Section 5= .7/TR-156." TR-177 R-30 "The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be able= to use Option 18 in order to retrieve the Access Node identifier and access th= is table in order to identify the ad-hoc pool of prefixes or addresses." & text in section 6.6 of TR-177 "In some deployments there is neither a need nor a desire to configure a gl= obal or unique local address to the interface on which the client messages are received. Such a = deployment does not allow the BNG to insert an IPv6 address in the link-address field. Having t= he BNG insert an Interface-Id option (Optoin 18) allows identification of the interface on w= hich the client messages are received, ... As introduced in this section, it can be deduced that the best solution for= a DHCPv6 Delegating Router or Server to identify the pool of prefixes to be used for assignment= consists of relying on the Interface-Id option (Optoin 18) inserted by the Access Node and more pr= ecisely on the Access Node identifier contained in this option. The operator must maintain a table binding the Access Node identifier with = the corresponding pool of prefixes. The DHCPv6 Delegating Router or DHCPv6 Server must be abl= e to use Option 18 in order to retrieve the Access Node identifier and access this table in= order to identify the adhoc pool of prefixes or addresses (see R-30). The main advantage of this solution is that it does not bring any requireme= nt to access or backhaul devices; additional functionality is only required on the DHCPv6 d= elegating router or server..." Note: Wojciech (Dec of Cisco) is the one of the editor of BBF-177 All of the above are still not the language of IETF, but the requirements f= rom the industry. The above text means the interface-id could be unique local in the administ= rator domain. Could the same logic be applied in the use cases of draft (OPTION_PREFIX_PO= OL), or we just to speak the pure IETF RFC's language? Best Regards, Leaf PS. Section 3.9.3 @ TR-101 Section 5.7 @ TR-156 -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Wednesday, April 17, 2013 7:49 PM To: Leaf Yeh Cc: Tomek Mrugalski; dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Resp= ond by April 8, 2013 Fyi - > To be more readable, the server can alternatively > use the Interface ID option included in the RELAY-FORW message by the > relay agent to identify the relay agent itself The interface id option can not be used to identify the relay. There is no = requirement that the interface id is globally unique - it only has signific= ance to the relay itself. - Bernie On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" > wrote: > Tomek - How about "Misconfigured or compromised DHCPv6 server can > cause relays to start announcing arbitrary prefixes, including default > routes, which could lead to traffic hijack."? > > I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't > bought in the part of 'Compromised DHCPv6 server'. I don't believe the > ORO option included by the relay could compromise the DHCPv6 server. Righ= t? > > >> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >> "The relay agent SHOULD include the Interface ID option")... > > Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: > "The server MAY use the link-address specified in RELAY-FORW message > to identify the relay agent itself or its particular customer-facing > interface where the prefix pool is associated, but the server has to > maintain the binding data of prefix pools in association with these > link-addresses. To be more readable, the server can alternatively > use the Interface ID option included in the RELAY-FORW message by the > relay agent to identify the relay agent itself or its particular > customer-facing interface where the prefix pool is associated. In > order to give a meaningful reply, the server has to maintain the > binding data of prefix pools in association with the information > derived from the Interface ID option." > The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both > use cases shown in section 3. > > > Tomek -RFC3315: relay MUST include interface-id if the link-address in > server's response is not sufficient to select downlink interface. > prefix-pool-opt-02: relay SHOULD include interface-id, so the the > server can identify the relay itself > (tomek: that's wrong. Interface-id is for interface or subnet > identification, not relay identification. Relay-id is used for that > purpose, see RFC5460, section 5.4.1) > > There might be a small debate here. The question could be whether the > server could identify the relay after receiving the interface-id of > it. I guess our smart server already support that in the real > deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 > (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: > The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be > able to use Option 18 in order to retrieve the Access Node identifier > and access this table in order to identify the ad-hoc pool of prefixes > or addresses.] > > OTOH, I believe relay-id defined in RFC5460 can also be used in the > case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. > 2); though if the mechanism of Bulk-Lease-Query is employed, the relay > also need to include OPTION_ RELAY_ID in the relay-forward message for > the basic operation of DHCPv6 prefix or address assignment. > > > Tomek - ... if the server would not like to use the link-address field > specified in RELAY-FORW message > (tomek: that imprecise or wrong. The server is not at liberty to "not > use link-address field". There's a specific algorithm defined in > section 11 of > RFC3315 that the server must follow it). > > Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, > has the following text: > " A server selects addresses to be assigned to an IA according to the > address assignment policies determined by the server administrator > and the specific information the server determines about the client > from some combination of the following sources: > - The link to which the client is attached. ... If the server > receives the message from a forwarding relay > agent, then the client is on the same link as the one to which > the interface, identified by the link-address field in the > message from the relay agent, is attached... > - The DUID supplied by the client. > - Other information in options supplied by the client. > - Other information in options supplied by the relay agent." > The above text sounds not put link-address ahead of options supplied > by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF > TR-177, its R-07, > R-08 & section6.6 (...In some deployments there is neither a need nor > a desire to configure a global or unique local address to the > interface on which the client messages are received. Such a deployment > does not allow the BNG to insert an IPv6 address in the link-address > field...).] > > > Best Regards, > Leaf > > > > -----Original Message----- > From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] > Sent: Sunday, April 14, 2013 8:26 PM > To: Leaf Yeh > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - > Respond by April 8, 2013 > > On 13-04-12 03:15, Leaf Yeh wrote: >> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? >> Your relay will hijack the whole network? ... >> >> The relay's behavior is still under control by the server. If it got >> the wrong configuration, the server could also send out ::/0 in the >> IA_PD. So this may sound an administration error. We just want the >> prefix pools not configure to be ::/0 or any overlap between them. I >> feel a little stuck on the exact text you want. How about 'The >> administrator of the DHCPv6 server should pay more attention to the >> configuration of the prefix pools, for examples, a. ::/0 may cause a >> big routing problem in the whole ISP network; b. the configuration of >> prefix pool should avoid overlap in the address plan, and etc.' ? I >> am > not quite sure... > Administrator mistake is one concern, the other one is that DHCPv6 > server may become an attractive attack target when prefix-pool is deploye= d. > > How about "Misconfigured or compromised DHCPv6 server can cause relays > to start announcing arbitrary prefixes, including default routes, > which could lead to traffic hijack."? > >> Tomek - Bernie had this concern and I tend to agree with him... the >> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my >> reply to Bernie's email. Thanks for your suggestion here. Do we need >> more explanation on the mathematic function of floor() ? :-) > I don't think so. A potential implementor who doesn't know what > floor() function does should probably consider starting a career in > some other industry. :-) > >> Tomek - ...(I know that requestor in most cases is part of a relay, >> but from protocol perspective these are separate entities)...Yes. >> Please split actions taken by requestor into separate section. It can >> be subsection 5.1 if you like to. >> >> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the >> section 5 "Relay Agent Behavior" (just for an editorial change)? Do >> you want section >> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? > Yes to both. > >> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >> "The relay agent SHOULD include the Interface ID option")... >> >> After searching and reading, I still can't find this sentence in RFC3315= . > It is in prefix-pool-opt-02, section 5, second paragraph. Text from > prefix-pool-opt-02 is an imprecise subset of behaviour described in > RFC3315, section 20.1.1, second paragraph. Here's the difference: > > RFC3315: relay MUST include interface-id if the link-address in > server's response is not sufficient to select downlink interface. > > prefix-pool-opt-02: relay SHOULD include interface-id, so the the > server can identify the relay itself (tomek: that's wrong. > Interface-id is for interface or subnet identification, not relay > identification. Relay-id is used for that purpose, see RFC5460, > section 5.4.1) if the server would not like to use the link-address field= specified in RELAY-FORW message (tomek: > that imprecise or wrong. The server is not at liberty to "not use > link-address field". There's a specific algorithm defined in section > 11 of > RFC3315 that the server must follow it). > > Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --_000_489D13FBFA9B3E41812EA89F188F018E1850E7D3xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, t= hat wasn’t a requirement in RFC 3315 so if this draft assumes that it= is (based on other standards), that needs to be clarified in the document = – that it requires the Interface-ID is sufficiently unique (as per [references]).

=  

-          Bernie

=  

From: Leaf Yeh [mailto:leaf.yeh.sdo@gmail.com]
Sent: Thursday, April 18, 2013 11:22 PM
To: Bernie Volz (volz)
Cc: 'Tomek Mrugalski'; 'Ted Lemon'
Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02= - Respond by April 8, 2013

 =

BV>= The interface id option can not be used to identify the relay. There is no requirement that the interface id is globa= lly unique - it only has significance to the rela= y itself.

&= nbsp;

The do= cuments of BBF TR-177 & TR-101 has different idea & requirements on= the usage of Interface-ID.

&= nbsp;

TR-177= R-07

“The Access Node MUST, when performing the function of an LDRA, be able to

encode= the access loop identification in the Interface-Id Option (option 18, defi= ned in

RFC 33= 15 [14]) and add the option to the DHCPv6 Relay-forward messages sent to

the BN= G, which acts as a DHCPv6 server or a DHCPv6 Relay Agent.”=

&= nbsp;

Note: = LDRA is the RA defined in RFC6221.

&= nbsp;

TR-177= R-08

“When adding the Interface-Id, the encoding MUST uniquely identify the Access

Node and the access loop logical port on the Access Node on which the DHCPv6

messag= e was received. The Interface-Id contains a locally administered = ASCII string

generated by the Access Node, representing the corresponding access loo= p logical

port (U interface). T= he actual syntax of the access loop identification in the Interface-

Id is = identical to the syntax defined in Section 3.9.3/TR-101 and= Section 5.7/TR-156.”

&= nbsp;

TR-177= R-30

“The BNG, when acting as a DHCPv6 Delegating Router or Server, M= UST be able to

use Option 18 in order to retrieve the Access Node identifier and acces= s this table in

order to identify the ad-hoc pool of prefixes or addresses.”

&= nbsp;

& = text in section 6.6 of TR-177

&= nbsp;

“In some deployments there is neither a need nor a desire to con= figure a global or unique local

addres= s to the interface on which the client messages are received. Such a deploy= ment does not

allow = the BNG to insert an IPv6 address in the link-address field. Having the BNG= insert an

Interf= ace-Id option (Optoin 18) allows identification of the interface on which t= he client

messag= es are received, …

&= nbsp;

As int= roduced in this section, it can be deduced that t= he best solution for a DHCPv6 Delegating

Router or Server to identify the pool of prefixes to be used for assign= ment consists of relying on

the Interface-Id option (Optoin 18) inserted by the Access Node and mor= e precisely on the

Access Node identifier contained in this option.

&= nbsp;

The operator must maintain a table binding the Access Node identifier w= ith the corresponding

pool of prefixes. The DHCPv6 Delegating Router or DHCPv6 Server must be= able to use Option

18 in order to retrieve the Access Node identifier and access this tabl= e in order to identify the adhoc

pool of prefixes or addresses (see R-30).

&= nbsp;

The ma= in advantage of this solution is that it does not bring any requirement to = access or

backha= ul devices; additional functionality is only required on the<= /span> DHCPv6 delegating router or

server…”

&= nbsp;

Note: = Wojciech (Dec of Cisco) is the one of the editor of BBF-177

&= nbsp;

&= nbsp;

All of the above are still not the language of IETF, but the requirements from the indust= ry.

&= nbsp;

The ab= ove text means the interface-id could be unique local in the administrator = domain.

&= nbsp;

Could = the same logic be applied in the use cases of draft (OPTION_PREFIX_POOL), o= r we just to speak the pure IETF RFC’s language?

&= nbsp;

&= nbsp;

Best R= egards,

Leaf

&= nbsp;

&= nbsp;

PS.

Sectio= n 3.9.3 @ TR-101

Sectio= n 5.7 @ TR-156

&= nbsp;

&= nbsp;

&= nbsp;

-----O= riginal Message-----

From: = Bernie Volz (volz) [mailto:volz@cisco.com= ]

Sent: = Wednesday, April 17, 2013 7:49 PM

To: Le= af Yeh

Cc: To= mek Mrugalski; dhcwg@ietf.org

Subjec= t: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by= April 8, 2013

&= nbsp;

Fyi - =

> T= o be more readable, the server can alternatively

>&n= bsp;  use the Interface ID option included in the RELAY-FORW message b= y the

>&n= bsp;  relay agent to identify the relay agent itself=

&= nbsp;

The in= terface id option can not be used to identify the relay. There is no requir= ement that the interface id is globally unique - it only has significance t= o the relay itself.

&= nbsp;

- Bern= ie

&= nbsp;

On Apr= 17, 2013, at 7:07 AM, "Leaf Yeh" <leaf.yeh.sdo@gmail.com> wrote:

&= nbsp;

> T= omek - How about "Misconfigured or compromised DHCPv6 server can

> c= ause relays to start announcing arbitrary prefixes, including default

> r= outes, which could lead to traffic hijack."?

> <= o:p>

> I= agree on the part of 'Mis-Configured DHCPv6 Server', but haven't

> b= ought in the part of 'Compromised DHCPv6 server'. I don't believe the

> O= RO option included by the relay could compromise the DHCPv6 server. Right?<= o:p>

> <= o:p>

> <= o:p>

>&g= t; Tomek - ...this draft repeats normative language from RFC3315 (e.g.

>&g= t; "The relay agent SHOULD include the Interface ID option")...

> <= o:p>

> S= ection 6 of the draft (OPTION_PREFIX_POOL) has the following text:

>&n= bsp; "The server MAY use the link-address specified in RELAY-FORW mess= age

>&n= bsp;  to identify the relay agent itself or its particular customer-fa= cing

>&n= bsp;  interface where the prefix pool is associated, but the server ha= s to

>&n= bsp;  maintain the binding data of prefix pools in association with th= ese

>&n= bsp;  link-addresses.  To be more readable, the server can altern= atively

>&n= bsp;  use the Interface ID option included in the RELAY-FORW message b= y the

>&n= bsp;  relay agent to identify the relay agent itself or its particular=

>&n= bsp;  customer-facing interface where the prefix pool is associated.&n= bsp; In

>&n= bsp;  order to give a meaningful reply, the server has to maintain the=

>&n= bsp;  binding data of prefix pools in association with the information=

>&n= bsp;  derived from the Interface ID option."

> T= he draft (OPTION_PREFIX_POOL) recommends to use interface-id for both

> u= se cases shown in section 3.

> <= o:p>

> <= o:p>

> T= omek -RFC3315: relay MUST include interface-id if the link-address in

> s= erver's response is not sufficient to select downlink interface.=

> p= refix-pool-opt-02: relay SHOULD include interface-id, so the the

> s= erver can identify the relay itself

> (= tomek: that's wrong. Interface-id is for interface or subnet

> i= dentification, not relay identification. Relay-id is used for that

> p= urpose, see RFC5460, section 5.4.1)

> <= o:p>

> T= here might be a small debate here. The question could be whether the

> s= erver could identify the relay after receiving the interface-id of

> i= t. I guess our smart server already support that in the real

> d= eployment. [Pls. refer to 'Access Node identifier' in BBF TR-177

> (= http://www.= broadband-forum.org/technical/trlist.php ) and its R-30:

> T= he BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be

> a= ble to use Option 18 in order to retrieve the Access Node identifier

> a= nd access this table in order to identify the ad-hoc pool of prefixes

> o= r addresses.]

> <= o:p>

> O= TOH, I believe relay-id defined in RFC5460 can also be used in the

> c= ase 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig.

> 2= ); though if the mechanism of Bulk-Lease-Query is employed, the relay

> a= lso need to include OPTION_ RELAY_ID in the relay-forward message for

> t= he basic operation of DHCPv6 prefix or address assignment.

> <= o:p>

> <= o:p>

> T= omek - ... if the server would not like to use the link-address field

> s= pecified in RELAY-FORW message

> (= tomek: that imprecise or wrong. The server is not at liberty to "not

> u= se link-address field". There's a specific algorithm defined in

> s= ection 11 of

> R= FC3315 that the server must follow it).

> <= o:p>

> S= ection 11 of RFC3315, Selecting Addresses for Assignment to an IA,

> h= as the following text:

>&n= bsp; " A server selects addresses to be assigned to an IA according to= the

>&n= bsp;  address assignment policies determined by the server administrat= or

>&n= bsp;  and the specific information the server determines about the cli= ent

>&n= bsp;  from some combination of the following sources:

>&n= bsp;  -  The link to which the client is attached. ... If the ser= ver

> r= eceives the message from a forwarding relay

>&n= bsp;        agent, then the client is on= the same link as the one to which

>&n= bsp;        the interface, identified by= the link-address field in the

>&n= bsp;        message from the relay agent= , is attached...

>&n= bsp;  -  The DUID supplied by the client.

>&n= bsp;  -  Other information in options supplied by the client.

>&n= bsp;  -  Other information in options supplied by the relay agent= ."

> T= he above text sounds not put link-address ahead of options supplied

> b= y the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF

> T= R-177, its R-07,

> R= -08 & section6.6 (...In some deployments there is neither a need nor

> a= desire to configure a global or unique local address to the

> i= nterface on which the client messages are received. Such a deployment

> d= oes not allow the BNG to insert an IPv6 address in the link-address

> f= ield...).]

> <= o:p>

> <= o:p>

> B= est Regards,

> L= eaf

> <= o:p>

> <= o:p>

> <= o:p>

> -= ----Original Message-----

> F= rom: Tomek Mrugalski [mailto:= tomasz.mrugalski@gmail.com]

> S= ent: Sunday, April 14, 2013 8:26 PM

> T= o: Leaf Yeh

> C= c: dhcwg@ietf.org

> S= ubject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -

> R= espond by April 8, 2013

> <= o:p>

> O= n 13-04-12 03:15, Leaf Yeh wrote:

>&g= t; Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option?

>&g= t; Your relay will hijack the whole network? ...

>&g= t;

>&g= t; The relay's behavior is still under control by the server. If it got

>&g= t; the wrong configuration, the server could also send out ::/0 in the

>&g= t; IA_PD. So this may sound an administration error. We just want the

>&g= t; prefix pools not configure to be ::/0 or any overlap between them. I

>&g= t; feel a little stuck on the exact text you want. How about 'The

>&g= t; administrator of the DHCPv6 server should pay more attention to the

>&g= t; configuration of the prefix pools, for examples, a. ::/0 may cause a

>&g= t; big routing problem in the whole ISP network; b. the configuration of

>&g= t; prefix pool should avoid overlap in the address plan, and etc.'  ?&= nbsp; I

>&g= t; am

> n= ot quite sure...

> A= dministrator mistake is one concern, the other one is that DHCPv6

> s= erver may become an attractive attack target when prefix-pool is deployed.<= o:p>

> <= o:p>

> H= ow about "Misconfigured or compromised DHCPv6 server can cause relays

> t= o start announcing arbitrary prefixes, including default routes,

> w= hich could lead to traffic hijack."?

> <= o:p>

>&g= t; Tomek - Bernie had this concern and I tend to agree with him... the

>&g= t; length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my

>&g= t; reply to Bernie's email. Thanks for your suggestion here. Do we need

>&g= t; more explanation on the mathematic function of floor() ? :-)<= /span>

> I= don't think so. A potential implementor who doesn't know what

> f= loor() function does should probably consider starting a career in

> s= ome other industry. :-)

> <= o:p>

>&g= t; Tomek - ...(I know that requestor in most cases is part of a relay,

>&g= t; but from protocol perspective these are separate entities)...Yes.

>&g= t; Please split actions taken by requestor into separate section. It can

>&g= t; be subsection 5.1 if you like to.

>&g= t;

>&g= t; Do you mean add section 5.1 "Leasequery Requestor Behavior" in= the

>&g= t; section 5 "Relay Agent Behavior" (just for an editorial change= )? Do

>&g= t; you want section

>&g= t; 6.1 "Leasequery Server Behavior" in section 6 "Server Beh= avior"?

> Y= es to both.

> <= o:p>

>&g= t; Tomek - ...this draft repeats normative language from RFC3315 (e.g.

>&g= t; "The relay agent SHOULD include the Interface ID option")...

>&g= t;

>&g= t; After searching and reading, I still can't find this sentence in RFC3315= .

> I= t is in prefix-pool-opt-02, section 5, second paragraph. Text from

> p= refix-pool-opt-02 is an imprecise subset of behaviour described in

> R= FC3315, section 20.1.1, second paragraph. Here's the difference:=

> <= o:p>

> R= FC3315: relay MUST include interface-id if the link-address in

> s= erver's response is not sufficient to select downlink interface.=

> <= o:p>

> p= refix-pool-opt-02: relay SHOULD include interface-id, so the the

> s= erver can identify the relay itself (tomek: that's wrong.

> I= nterface-id is for interface or subnet identification, not relay

> i= dentification. Relay-id is used for that purpose, see RFC5460,

> s= ection 5.4.1) if the server would not like to use the link-address field sp= ecified in RELAY-FORW message (tomek:

> t= hat imprecise or wrong. The server is not at liberty to "not use

> l= ink-address field". There's a specific algorithm defined in section

> 1= 1 of

> R= FC3315 that the server must follow it).

> <= o:p>

> T= omek

> <= o:p>

> _= ______________________________________________

> d= hcwg mailing list

> <= a href=3D"mailto:dhcwg@ietf.org"> dhcwg@ietf.org

> <= a href=3D"https://www.ietf.org/mailman/listinfo/dhcwg"> https://www.ietf.org/mailman/listinfo/dhcwg

--_000_489D13FBFA9B3E41812EA89F188F018E1850E7D3xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Thu Apr 18 22:57:59 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2321F8EA8 for ; Thu, 18 Apr 2013 22:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 LzQx6M4tEKHF for ; Thu, 18 Apr 2013 22:57:58 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6514621F85EB for ; Thu, 18 Apr 2013 22:57:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUXDc5q4y1E0JErLraLcWCBsvrFts0wq1@postini.com; Thu, 18 Apr 2013 22:57:58 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 BA2AE1B8138 for ; Thu, 18 Apr 2013 22:57:57 -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 AEB51190052; Thu, 18 Apr 2013 22:57:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 22:57:57 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: AQHOPK0oNCF/TVZcZkWki5IMitlTr5jdV5oAgAAqEQA= Date: Fri, 19 Apr 2013 05:57:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751511C2@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com> <5170b87e.8abd440a.4b9d.ffffb77a@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1850E7D3@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850E7D3@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751511C2mbx01winnominum_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 05:57:59 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751511C2mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 18, 2013, at 11:27 PM, "Bernie Volz (volz)" > wrote: OK, that wasn=92t a requirement in RFC 3315 so if this draft assumes that i= t is (based on other standards), that needs to be clarified in the document= =96 that it requires the Interface-ID is sufficiently unique (as per [refe= rences]). I'm skeptical that there is any presumption of uniqueness to the interface = ID alone; combined with the IP address of the relay agent, you have a uniqu= e identifier. Leaf, do you have any direct experience with this sort of c= onfiguration? --_000_8D23D4052ABE7A4490E77B1A012B6307751511C2mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <15E19C51C40BBA4C8891B645B1843A23@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 18, 2013, at 11:27 PM, "Bernie Volz (volz)" <volz@cisco.com> wrote:
OK, that wasn=92t a requirement in RFC 3315 so if this draft assumes that it i= s (based on other standards), that needs to be clarified in the document = =96 that it requires the Interface-ID is sufficiently unique (as per [refer= ences]).

I'm skeptical that there is any presumption of uniqueness to the inter= face ID alone; combined with the IP address of the relay agent, you have a = unique identifier.   Leaf, do you have any direct experience with this= sort of configuration?

--_000_8D23D4052ABE7A4490E77B1A012B6307751511C2mbx01winnominum_-- From tomasz.mrugalski@gmail.com Thu Apr 18 23:03:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCC121F8EB7 for ; Thu, 18 Apr 2013 23:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_LH_HOME=3.714, RDNS_DYNAMIC=0.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 wQ2QXMJdbQem for ; Thu, 18 Apr 2013 23:03:39 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C41B821F8F2F for ; Thu, 18 Apr 2013 23:03:33 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id s35so1781718dak.20 for ; Thu, 18 Apr 2013 23:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=2H5TM2iZQkZgmaKyWtBpw8Vdt20PvVjI1LjtVPP8qFo=; b=RW7My6/pfAgsYJVgMMLjyJYKng25Xynxz1uOritUa8QJ5ncgR+Ia1cHC125/mRjByM iyPsAipx3vfRaEzqivUWD5+74JZr2ahjNUfRvvdEZ4YEUOqWkHirQN/Vnrr5FOcC1U1F l4T8WJ5HSK4n7f6z1En6zfGvuIBQzd6DcYfh5UhxdRQ1X6JriCAKn8D4bmDdAAQK1h1x VN5l/t/ws3rIBE1oaJ51xXalNj1Mt/iST9cySOVp1WrXXUtqXiz2xdzCdYbaxaZBWpGl e42b2knM8ovbHUA3Z8dOjKrIJU7dZwRRxVHJ21DbDJwRTfD5LjrmOkzWdcok8pVoq+qX q1cQ== X-Received: by 10.68.170.66 with SMTP id ak2mr16953438pbc.123.1366351407744; Thu, 18 Apr 2013 23:03:27 -0700 (PDT) Received: from thomson-osx.lan (dsl092-002-166.sfo1.dsl.speakeasy.net. [66.92.2.166]) by mx.google.com with ESMTPS id xl10sm13470917pac.15.2013.04.18.23.03.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 23:03:26 -0700 (PDT) Message-ID: <5170DE2C.4010200@gmail.com> Date: Thu, 18 Apr 2013 23:03:24 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <515D592B.4040609@viagenie.ca> In-Reply-To: <515D592B.4040609@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 06:03:40 -0000 On 2013-04-03 19:40, Tomek Mrugalski wrote: > As requested by authors, we are announcing adotion call on > draft-scskf-dhc-dhcpv4-over-dhcpv6-01. This call is being initiated to > confirm whether there is WG consensus to adopt this work as DHC WG > draft. Please state whether or not you're in favor of the adoption by > replying to this mail. If you are not in favor, please also state your > objections in your response. This adoption call will complete on > 2013-04-17. This adoption call deadline has passed. I'm very happy that we had a healthy discussion with many useful comments posted. Most comments were supporting adoption. There were two objections (one was later withdrawn). This means that the WG has reached a strong consensus to adopt this work. Authors, please upload this work as draft-ietf-dhc-dhcpv4-over-dhcpv6-00 once you address all received comments. Bernie & Tomek From tomasz.mrugalski@gmail.com Thu Apr 18 23:52:36 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBE121F90EE for ; Thu, 18 Apr 2013 23:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_LH_HOME=3.714, RDNS_DYNAMIC=0.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 KWBoytQT+apK for ; Thu, 18 Apr 2013 23:52:32 -0700 (PDT) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 06CFC21F9079 for ; Thu, 18 Apr 2013 23:52:28 -0700 (PDT) Received: by mail-da0-f51.google.com with SMTP id g27so1797786dan.38 for ; Thu, 18 Apr 2013 23:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=pNb0YLIDRtytXr3me9dhFcS0hjI0duTQ0P93he88tMw=; b=GTJDw783gOpqAiE0FQp7PD+SP7szbsRa2tDVhJBbWKaaFiZPlelHrsb5uweddoClgp g3HsAZD5OXEzh4mAva5mVJ+t+M4eMsu6PmBO6d8DjY9KvXwW9btZv6ivQ34aFSSobVVM OMVXCNWtQxBaNukHjopDAPsb5cx66Zvrbuz9ALDyzEadyTgcRbYRL+GLbL61en3l2KKh DhGzu9dFHWvtP6WkOlNCvZXT73oKdukHqtQ03LfyIQehjt570mzqjERvR9RX4O8lmZmo 0Ufv2m+koGu+8r+kky5pmmjDr8WFXmzq6oS6FrRFGM2Zi7omeAGzWEJf+Fu7gAyw95s/ 0juQ== X-Received: by 10.68.35.166 with SMTP id i6mr17235093pbj.221.1366354348747; Thu, 18 Apr 2013 23:52:28 -0700 (PDT) Received: from thomson-osx.lan (dsl092-002-166.sfo1.dsl.speakeasy.net. [66.92.2.166]) by mx.google.com with ESMTPS id ak5sm13644022pac.4.2013.04.18.23.52.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 23:52:28 -0700 (PDT) Message-ID: <5170E9AA.9030806@gmail.com> Date: Thu, 18 Apr 2013 23:52:26 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg References: <31BA50D5-3451-49B7-8139-8244A3E90F7A@gmail.com> <515C6627.5060401@gmail.com> In-Reply-To: <515C6627.5060401@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 06:52:36 -0000 On 13-04-03 10:25, Tomek Mrugalski wrote: > Authors requested adoption call on > draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being > initiated to confirm whether there is WG consensus to adopt this work > as DHC WG draft. Please state whether or not you're in favor of the > adoption by replying to this mail. If you are not in favor, please > also state your objections in your response. This adoption call will > complete on 2013-04-17. This message summarizes adoption call for draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. Several folks expressed their support for this work, with noone objecting. I was hoping for more broad support, but this has not materialized. Fortunately, chairs feel that the number of supporters is sufficient to say that the WG consensus is to adopt this work. Authors, please address all received comments that were raised during adoption call and upload your draft as draft-ietf-dhc-dhcpv6-unknown-msg. The "-3315update" is not necessary in the draft name. Cheers, Bernie & Tomek From leaf.yeh.sdo@gmail.com Fri Apr 19 01:43:58 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2042E21F84CE for ; Fri, 19 Apr 2013 01:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.929 X-Spam-Level: * X-Spam-Status: No, score=1.929 tagged_above=-999 required=5 tests=[AWL=-2.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 c1ZLDWkeC0Yw for ; Fri, 19 Apr 2013 01:43:56 -0700 (PDT) Received: from mail-da0-x229.google.com (mail-da0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 47C2621F8A2A for ; Fri, 19 Apr 2013 01:43:56 -0700 (PDT) Received: by mail-da0-f41.google.com with SMTP id p8so1727199dan.14 for ; Fri, 19 Apr 2013 01:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=iN6QclkpJR0+jGD6YlHQPPXhE5dfw5cFIwbe6lsxtV4=; b=JvZEt5/B1DGQntOyneaIqk7yYqQz9o+3j1FAoSaQ/sRvWLSZP7cBkgKnaStZotX1HX SevdyIfmhL86RCxOmXskQjXKovMeUSvuUfUvL03suPcjSfoLUQcOrevE5TG9E1XykkOA /xcrvfQ2qi21HKBSSycpp55RXXL0BMjAilM5q6LTbN1Qt5ZHj0oC4+67Vrzb5+r8yTCo DFoDsbMrsgZM3QGUIBgSGNYdru+DSabLpbFKoTWx4ePWh5A6Bo+eswbuK9brOI3uU9+T hqBKUjQycQaWJUCVdf3I6QdiRdPfni27UukviwndCecVt2IL7my+qcY/+gUemSzSXxZO 1zpA== X-Received: by 10.68.105.33 with SMTP id gj1mr18107711pbb.13.1366361036040; Fri, 19 Apr 2013 01:43:56 -0700 (PDT) Received: from PC ([61.48.185.127]) by mx.google.com with ESMTPS id s1sm1500218pab.22.2013.04.19.01.43.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 19 Apr 2013 01:43:55 -0700 (PDT) From: "Leaf Yeh" To: "'Ted Lemon'" , "'Bernie Volz \(volz\)'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com> <5170b87e.8abd440a.4b9d.ffffb77a@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1850E7D3@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751511C2@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751511C2@mbx-01.win.nominum.com> Date: Fri, 19 Apr 2013 16:43:47 +0800 Message-ID: <517103cb.c10b420a.04ef.ffff8ddf@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CE3D1D.13366180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOPK0oNCF/TVZcZkWki5IMitlTr5jdV5oAgAAqEQD//427IA== Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 08:43:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006F_01CE3D1D.13366180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ted - .the interface ID.combined with the IP address of the relay agent, you have a unique identifier. That is a good idea, we do have the Global Unicast Address (GUA) on the relay (or its network-facing interface) for the communication between the relay and the server. It sound much better than DUID, which sounds associated with the hardware to get the global uniqueness. Ted - . do you have any direct experience with this sort of configuration? The Broadband Forum Technical Reports (TR-101/156/177-IPv6) are mostly for the spec. (or requirements) of access network equipments. They do have Access Node Identifier included in the Interface-ID (Table 2 in TR-101 titled Circuit ID Syntax & Table 1 in TR-156 titled Port Identification String Elements) for Layer 2 DHCP relay agent (or PPPoE Intermediate Agent) on the Access Node. That makes the interface-id be unique-local in the administrator domain, which sounds a Must when a PE router connect multiple Access Nodes through Ethernet. In their use cases, the access nodes (or even LDRAs) don't always have the IPv6-GUAs in their control (or protocol)-plane. The previous versions of my draft try to apply the same idea as that of TR-177, but it employ the administrative unique interface-id for layer-3 device, a PE router. So we don't have any direct experience with this sort of configuration yet. But in theory there sounds no difference whether the relay is layer-2 or layer-3, when the relay include interface-id. The administrative unique interface-id might be more readable than IPv6-GUA when configuring the binding relationship with prefix pools on the server, but sounds a little more administrative. Thanks to Tomek for his catch to this further discussion. Best Regards, Leaf From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Friday, April 19, 2013 1:58 PM To: Bernie Volz (volz) Cc: Leaf Yeh; Tomek Mrugalski; dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 On Apr 18, 2013, at 11:27 PM, "Bernie Volz (volz)" wrote: OK, that wasn't a requirement in RFC 3315 so if this draft assumes that it is (based on other standards), that needs to be clarified in the document - that it requires the Interface-ID is sufficiently unique (as per [references]). I'm skeptical that there is any presumption of uniqueness to the interface ID alone; combined with the IP address of the relay agent, you have a unique identifier. Leaf, do you have any direct experience with this sort of configuration? ------=_NextPart_000_006F_01CE3D1D.13366180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted - …the interface = ID…combined = with the IP address of the relay agent, you have a unique = identifier.

 

That is a good idea, we do have the Global Unicast Address (GUA) on = the relay (or its network-facing interface) for the communication = between the relay and the server. It sound much better than DUID, which = sounds associated with the hardware to get the global uniqueness. =

 

 

Ted - … do you have any = direct experience with this sort of = configuration?

 

The Broadband Forum Technical Reports (TR-101/156/177-IPv6) are = mostly  for the spec. (or requirements) of access network = equipments. They do have Access Node Identifier included in the = Interface-ID (Table 2 in TR-101 titled Circuit ID Syntax & Table 1 = in TR-156 titled Port Identification String Elements) for Layer 2 DHCP = relay agent (or PPPoE Intermediate Agent) on the Access Node. That makes = the interface-id be unique-local in the administrator domain, which = sounds a Must when a PE router connect multiple Access Nodes through = Ethernet. In their use cases, the access nodes (or even LDRAs) = don’t always have the IPv6-GUAs in their control (or = protocol)-plane.

 

The previous versions of my draft try to apply the same idea as that = of TR-177,  but it employ the administrative unique interface-id = for layer-3 device, a PE router. So we don’t have any direct = experience with this sort of configuration yet. But in theory there = sounds no difference whether the relay is layer-2 or layer-3, when the = relay include interface-id.

 

The administrative unique interface-id might be more readable than = IPv6-GUA when configuring the binding relationship with prefix pools on = the server, but sounds a little more administrative. =

 

Thanks to Tomek for his catch to this further = discussion.

 

 

Best Regards,

Leaf

 

 

 

From:= Ted Lemon = [mailto:Ted.Lemon@nominum.com]
Sent: Friday, April 19, 2013 = 1:58 PM
To: Bernie Volz (volz)
Cc: Leaf Yeh; Tomek = Mrugalski; dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC - = draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, = 2013

 

On Apr 18, 2013, at 11:27 PM, = "Bernie Volz (volz)" <volz@cisco.com> wrote:

OK, that wasn’t a requirement in RFC 3315 so if this draft = assumes that it is (based on other standards), that needs to be = clarified in the document – that it requires the Interface-ID is = sufficiently unique (as per [references]).

 

I'm skeptical that there is any = presumption of uniqueness to the interface ID alone; combined with the = IP address of the relay agent, you have a unique identifier.   = Leaf, do you have any direct experience with this sort of = configuration?

 

------=_NextPart_000_006F_01CE3D1D.13366180-- From volz@cisco.com Fri Apr 19 05:15:58 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3814621F955E for ; Fri, 19 Apr 2013 05:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgnyD8iuuUHH for ; Fri, 19 Apr 2013 05:15:57 -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 BC9D321F9427 for ; Fri, 19 Apr 2013 05:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11939; q=dns/txt; s=iport; t=1366373756; x=1367583356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oLMP7je9IrWQe3O38t0fIq7Gz+C8hn2G0qU5nTisWeQ=; b=lI1Z1OFUZKUr7ZIGR+uSJroqn6GG2f1Wmm7lxg4a6o2vcjCAo2I8Wyqs kuMpCUCbespgS6sSrgZpsXWa2QXp0HunLIIh4laM5MKwJ/O/YpmvKznPz TLBfJtVrEyJx9lPgM1ozc+thbFBOGUh36glkJo2y+Sqp8qLwnO8aw2X6L o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAH40cVGtJXHA/2dsb2JhbAA2EAqDBjbAYoEGFnSCHwEBAQMBAQEBNzQLBQcEAgEIEQQBAQEeCQchBgsUCQgCBA4FiAIDCQYML7MTDYldjEWBEQaBCSgGBQcGgmBhA5M6gWqBY4tyBoUcgVWBNoFz X-IronPort-AV: E=Sophos;i="4.87,508,1363132800"; d="scan'208";a="200481138" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 19 Apr 2013 12:15:55 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3JCFtRJ029301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 12:15:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 07:15:55 -0500 From: "Bernie Volz (volz)" To: Leaf Yeh Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Thread-Index: AQHOPKzovogHcM1pY0u5AcHSatDsXpjdde7n Date: Fri, 19 Apr 2013 12:15:55 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com>, <5170b80d.0d43420a.09e7.ffffd707@mx.google.com> In-Reply-To: <5170b80d.0d43420a.09e7.ffffd707@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 12:15:58 -0000 Yes, using relay-id should solve the problem of uniquess. Lacking that, per= haps GUA can be used but is not as good.=20 Server does not echo back relay-id unless Relay asked it to using the ERO. - Bernie On Apr 18, 2013, at 11:20 PM, "Leaf Yeh" wrote: > BV> The interface id option can not be used to identify the relay. There = is > no requirement that the interface id is globally unique - it only has > significance to the relay itself. >=20 > If we decide to come back & comply with the exact language of IETF define= d > before, how about to update the text in section 5 to be=20 >=20 > "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, 53)= or > Interface ID option (OPTION_INTERFACE_ID, 18) so that the server can > identify the relay agent itself or its particular customer-facing interfa= ce > with which the prefix pool is associated, if the server can not use the > link-address field specified in the encapsulation of the DHCPv6 RELAY-FOR= W > message to identify the interface of the link on which the clients are > located." >=20 > and the text in section 6 to be >=20 > "The server MAY use the link-address specified in RELAY-FORW message to > identify the relay agent itself and its particular customer-facing interf= ace > where the prefix pool is associated, but the server has to maintain the > binding data of prefix pools in association with these link-addresses. To= be > more readable, the server can alternatively use Relay-ID and Interface-ID > option included in the RELAY-FORW message by the relay agent to identify = the > relay agent itself and its particular customer-facing interface where the > prefix pool is associated. In order to give a meaningful reply, the serve= r > has to maintain the binding data of prefix pools in association with thes= e > Relay-ID and Interface-ID. According to DHCPv6 [RFC3315], the server SHOU= LD > copy the Interface-ID option from the RELAY-FORW message into the RELAY-R= EPL > message." >=20 >=20 > Does the server need to copy Relay-ID from the RELAY-FORW into the > RELAY-REPL? >=20 >=20 > Best Regards, > Leaf >=20 > PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly. >=20 >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Wednesday, April 17, 2013 7:49 PM > To: Leaf Yeh > Cc: Tomek Mrugalski; dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - > Respond by April 8, 2013 >=20 > Fyi -=20 >> To be more readable, the server can alternatively >> use the Interface ID option included in the RELAY-FORW message by the >> relay agent to identify the relay agent itself >=20 > The interface id option can not be used to identify the relay. There is n= o > requirement that the interface id is globally unique - it only has > significance to the relay itself. >=20 > - Bernie >=20 > On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" wrote: >=20 >> Tomek - How about "Misconfigured or compromised DHCPv6 server can=20 >> cause relays to start announcing arbitrary prefixes, including default=20 >> routes, which could lead to traffic hijack."? >>=20 >> I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't=20 >> bought in the part of 'Compromised DHCPv6 server'. I don't believe the=20 >> ORO option included by the relay could compromise the DHCPv6 server. > Right? >>=20 >>=20 >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g.=20 >>> "The relay agent SHOULD include the Interface ID option")... >>=20 >> Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: >> "The server MAY use the link-address specified in RELAY-FORW message >> to identify the relay agent itself or its particular customer-facing >> interface where the prefix pool is associated, but the server has to >> maintain the binding data of prefix pools in association with these >> link-addresses. To be more readable, the server can alternatively >> use the Interface ID option included in the RELAY-FORW message by the >> relay agent to identify the relay agent itself or its particular >> customer-facing interface where the prefix pool is associated. In >> order to give a meaningful reply, the server has to maintain the >> binding data of prefix pools in association with the information >> derived from the Interface ID option." >> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for both=20 >> use cases shown in section 3. >>=20 >>=20 >> Tomek -RFC3315: relay MUST include interface-id if the link-address in=20 >> server's response is not sufficient to select downlink interface. >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the=20 >> server can identify the relay itself >> (tomek: that's wrong. Interface-id is for interface or subnet=20 >> identification, not relay identification. Relay-id is used for that=20 >> purpose, see RFC5460, section 5.4.1) >>=20 >> There might be a small debate here. The question could be whether the=20 >> server could identify the relay after receiving the interface-id of=20 >> it. I guess our smart server already support that in the real=20 >> deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177=20 >> (http://www.broadband-forum.org/technical/trlist.php ) and its R-30:=20 >> The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be=20 >> able to use Option 18 in order to retrieve the Access Node identifier=20 >> and access this table in order to identify the ad-hoc pool of prefixes=20 >> or addresses.] >>=20 >> OTOH, I believe relay-id defined in RFC5460 can also be used in the=20 >> case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig.=20 >> 2); though if the mechanism of Bulk-Lease-Query is employed, the relay=20 >> also need to include OPTION_ RELAY_ID in the relay-forward message for=20 >> the basic operation of DHCPv6 prefix or address assignment. >>=20 >>=20 >> Tomek - ... if the server would not like to use the link-address field=20 >> specified in RELAY-FORW message >> (tomek: that imprecise or wrong. The server is not at liberty to "not=20 >> use link-address field". There's a specific algorithm defined in=20 >> section 11 of >> RFC3315 that the server must follow it). >>=20 >> Section 11 of RFC3315, Selecting Addresses for Assignment to an IA,=20 >> has the following text: >> " A server selects addresses to be assigned to an IA according to the >> address assignment policies determined by the server administrator >> and the specific information the server determines about the client >> from some combination of the following sources: >> - The link to which the client is attached. ... If the server=20 >> receives the message from a forwarding relay >> agent, then the client is on the same link as the one to which >> the interface, identified by the link-address field in the >> message from the relay agent, is attached... >> - The DUID supplied by the client. >> - Other information in options supplied by the client. >> - Other information in options supplied by the relay agent." >> The above text sounds not put link-address ahead of options supplied=20 >> by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF=20 >> TR-177, its R-07, >> R-08 & section6.6 (...In some deployments there is neither a need nor=20 >> a desire to configure a global or unique local address to the=20 >> interface on which the client messages are received. Such a deployment=20 >> does not allow the BNG to insert an IPv6 address in the link-address=20 >> field...).] >>=20 >>=20 >> Best Regards, >> Leaf >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >> Sent: Sunday, April 14, 2013 8:26 PM >> To: Leaf Yeh >> Cc: dhcwg@ietf.org >> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -=20 >> Respond by April 8, 2013 >>=20 >> On 13-04-12 03:15, Leaf Yeh wrote: >>> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option?=20 >>> Your relay will hijack the whole network? ... >>>=20 >>> The relay's behavior is still under control by the server. If it got=20 >>> the wrong configuration, the server could also send out ::/0 in the=20 >>> IA_PD. So this may sound an administration error. We just want the=20 >>> prefix pools not configure to be ::/0 or any overlap between them. I=20 >>> feel a little stuck on the exact text you want. How about 'The=20 >>> administrator of the DHCPv6 server should pay more attention to the=20 >>> configuration of the prefix pools, for examples, a. ::/0 may cause a=20 >>> big routing problem in the whole ISP network; b. the configuration of=20 >>> prefix pool should avoid overlap in the address plan, and etc.' ? I=20 >>> am >> not quite sure... >> Administrator mistake is one concern, the other one is that DHCPv6=20 >> server may become an attractive attack target when prefix-pool is > deployed. >>=20 >> How about "Misconfigured or compromised DHCPv6 server can cause relays=20 >> to start announcing arbitrary prefixes, including default routes,=20 >> which could lead to traffic hijack."? >>=20 >>> Tomek - Bernie had this concern and I tend to agree with him... the=20 >>> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my=20 >>> reply to Bernie's email. Thanks for your suggestion here. Do we need=20 >>> more explanation on the mathematic function of floor() ? :-) >> I don't think so. A potential implementor who doesn't know what=20 >> floor() function does should probably consider starting a career in=20 >> some other industry. :-) >>=20 >>> Tomek - ...(I know that requestor in most cases is part of a relay,=20 >>> but from protocol perspective these are separate entities)...Yes. >>> Please split actions taken by requestor into separate section. It can=20 >>> be subsection 5.1 if you like to. >>>=20 >>> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the=20 >>> section 5 "Relay Agent Behavior" (just for an editorial change)? Do=20 >>> you want section >>> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? >> Yes to both. >>=20 >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g.=20 >>> "The relay agent SHOULD include the Interface ID option")... >>>=20 >>> After searching and reading, I still can't find this sentence in RFC331= 5. >> It is in prefix-pool-opt-02, section 5, second paragraph. Text from >> prefix-pool-opt-02 is an imprecise subset of behaviour described in=20 >> RFC3315, section 20.1.1, second paragraph. Here's the difference: >>=20 >> RFC3315: relay MUST include interface-id if the link-address in=20 >> server's response is not sufficient to select downlink interface. >>=20 >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the=20 >> server can identify the relay itself (tomek: that's wrong.=20 >> Interface-id is for interface or subnet identification, not relay=20 >> identification. Relay-id is used for that purpose, see RFC5460,=20 >> section 5.4.1) if the server would not like to use the link-address fiel= d > specified in RELAY-FORW message (tomek: >> that imprecise or wrong. The server is not at liberty to "not use=20 >> link-address field". There's a specific algorithm defined in section=20 >> 11 of >> RFC3315 that the server must follow it). >>=20 >> Tomek >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rghai@benunets.com Fri Apr 19 06:17:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5836321F95E4 for ; Fri, 19 Apr 2013 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6wHF7kMb1ZQq for ; Fri, 19 Apr 2013 06:17:00 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 2C08621F95E2 for ; Fri, 19 Apr 2013 06:16:57 -0700 (PDT) Received: from mail-oa0-f70.google.com ([209.85.219.70]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUXFDyboGhBvmyMOR6xL5L6vfMBKIoU/S@postini.com; Fri, 19 Apr 2013 06:17:00 PDT Received: by mail-oa0-f70.google.com with SMTP id n9so23975254oag.5 for ; Fri, 19 Apr 2013 06:16:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CBGCdAShNQ4AAE1boGf4w6+JPk2H3mkDsSVrPC3o0S0=; b=MoSsNf/GBy61xdQ7A9i1zInU1mr7u2LPSutCwM5htHvqcztc43CngATyjLMpWZM0vV r/LjRKnRxFVSjixQKFpnyquzgRMmQxjI2a54G+SMcP4L1N2OhhqNCcz1ePKGkzcjpQV2 D0T6MO0oXxao4/IGD+AKP4VWK+jU+eqJPVklIkTEMgQF2hBs1yGQXwlXXklN9NW7P6UC dar3IaN+Z0DwVqqwWRYCboCqT/T8puPS6pisOLv3/Ezh/IZ5wTyG/asFFHpUr0UPkzyW iYmVFjTuUSg6H7x4Onnwo1vmK3onby82vaWFDBDh5iZdd0eQzv6USolJYdOJ1DmCOvWv UWvA== X-Received: by 10.50.129.66 with SMTP id nu2mr1784134igb.0.1366377416721; Fri, 19 Apr 2013 06:16:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.129.66 with SMTP id nu2mr1782849igb.0.1366377386096; Fri, 19 Apr 2013 06:16:26 -0700 (PDT) Received: by 10.64.252.195 with HTTP; Fri, 19 Apr 2013 06:16:24 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> Date: Fri, 19 Apr 2013 09:16:24 -0400 Message-ID: From: Rajat Ghai To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=047d7b4142f8ba6b5e04dab686d1 X-Gm-Message-State: ALoCoQmebJVmRwifOZfc48BsdJDGtVrYHx88PZdDNllTG94EIMdP7UJxYZcQUXKlVSYno/sAWpxcVgsVPT8eniQ85kMMKi9vllQfxJjm/32KVFAscTD86YzNowpO0VP3z8DcIoRW4SLopFCfbrw4kZIfp1EC/ygJDw== Cc: "dhcwg@ietf.org" , Florin Baboescu , Ted Lemon , Jouni Korhonen , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 13:17:01 -0000 --047d7b4142f8ba6b5e04dab686d1 Content-Type: text/plain; charset=ISO-8859-1 Tend to agree with Sri here .. Not only this Access-Network-Info be used in the Wi-Fi domain ; but in some cases be further transported to the mobile packet core (EPC) in case the user happens to be registered user of a mobile operator and the IP address is eventually allocated from the EPC. Current definition of Option 82 is not enough to carry all the required information. Rajat Ghai CTO Benu Networks On Wed, Apr 17, 2013 at 11:47 AM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Hi Ted, > > Thanks for your comments. > > This requirement is not coming from any SDO. We believe this is a generic > requirement for IETF based IP architectures. > > As you are aware, many operators are deploying large scale SP WiFI > networks. These deployments are based on standard IETF protocols and > architectures (tunneling, mobility, Routing, AAA protocols ...). In many > of these deployments the subscriber services are tied to the access > network, for example, the initial portal page may be different based on > the user location (SSID, AP Mac address ..). These parameters are > typically carried on DHCP option-82, and are coded in a vendor basis. > There is no standard encoding that a backend system can reliably depend on > for learning these parameters. In the past when WiFI was largely contained > to enterprises, with single vendor solutions, this worked fine. But, now > in many deployments there are multi-vendor systems and interop is > required. The draft is trying to attempt to fix that gap. We want to drive > this work in DHC, not using a liaison statement, but as a gap in IETF > protocols, to solve a practical deployment issue and improve > interoperability. > > I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI > networks and he can comment on this. > > > > > Regards > Sri > > > > > > > > > > > > On 4/17/13 7:59 AM, "Ted Lemon" wrote: > > >When we talked about this earlier, I said that it might be better to have > >this work done in DHC rather than forcing it to find a new working group > >because it seemed to be something that was being asked for by other SDOs. > > However, the authors never said anything about that over and above what > >they've already said in meetings, so I don't actually have a clear > >picture of who is asking for this. Looking in the data tracker, I don't > >find any liaison statement requesting that this work be done. > > > >The authors have expressed a great deal of urgency about this work, and I > >don't want to delay it any further, so I will state that as a > >participant, I'm in favor of the working group taking on the work. > >However, with my AD hat on, I would like to get some kind of actual > >request for help from the SDOs who want this functionality before the end > >of the call for adoption. Otherwise I think Bernie's concern that the > >DHC working group really isn't qualified to evaluate the validity of the > >option contents will remain unaddressed, and I think it's a valid concern. > > > >The request from the SDOs should be of the form "we need DHCP options to > >deliver the following bits of functionality," and should briefly describe > >the functionality that's needed, and refer to the documents that the SDO > >is working on that support this need. > > > >If this need is not really coming from these SDOs, but rather from some > >IETF working group, then perhaps Bernie's original observation was > >correct, and this work should be done in that working group instead. > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Best Regards Rajat Ghai CTO Benu Networks (www.benunets.com) --047d7b4142f8ba6b5e04dab686d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tend to agree with Sri here .. =A0Not only this Access-Net= work-Info be used in the Wi-Fi domain ; but in some cases be further transp= orted to the mobile packet core (EPC) in case the user happens to be regist= ered user of a mobile operator and the IP address is eventually allocated f= rom the EPC. Current definition of Option 82 is not enough to carry all the= required information.

Rajat Ghai
CTO
Benu Ne= tworks


On Wed, Apr 17, 2013 at 11:47 AM, Sri Gundavelli (sgundave) <sgunda= ve@cisco.com> wrote:
Hi Ted,

Thanks for your comments.

This requirement is not coming from any SDO. We believe this is a generic requirement for IETF based IP architectures.

As you are aware, many operators are deploying large scale SP WiFI
networks. These deployments are based on standard IETF protocols and
architectures (tunneling, mobility, Routing, AAA protocols ...). In many of these deployments the subscriber services are tied to the access
network, for example, the initial portal page may be different based on
the user location (SSID, AP Mac address ..). These parameters are
typically carried on DHCP option-82, and are coded in a vendor basis.
There is no standard encoding that a backend system can reliably depend on<= br> for learning these parameters. In the past when WiFI was largely contained<= br> to enterprises, with single vendor solutions, this worked fine. But, now in many deployments there are multi-vendor systems and interop is
required. The draft is trying to attempt to fix that gap. We want to drive<= br> this work in DHC, not using a liaison statement, but as a gap in IETF
protocols, to solve a practical deployment issue and improve
interoperability.

I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI
networks and he can comment on this.




Regards
Sri











On 4/17/13 7:59 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

>When we talked about this earlier, I said that it might be better to ha= ve
>this work done in DHC rather than forcing it to find a new working grou= p
>because it seemed to be something that was being asked for by other SDO= s.
> =A0However, the authors never said anything about that over and above = what
>they've already said in meetings, so I don't actually have a cl= ear
>picture of who is asking for this. =A0 Looking in the data tracker, I d= on't
>find any liaison statement requesting that this work be done.
>
>The authors have expressed a great deal of urgency about this work, and= I
>don't want to delay it any further, so I will state that as a
>participant, I'm in favor of the working group taking on the work.<= br> >However, with my AD hat on, I would like to get some kind of actual
>request for help from the SDOs who want this functionality before the e= nd
>of the call for adoption. =A0 Otherwise I think Bernie's concern th= at the
>DHC working group really isn't qualified to evaluate the validity o= f the
>option contents will remain unaddressed, and I think it's a valid c= oncern.
>
>The request from the SDOs should be of the form "we need DHCP opti= ons to
>deliver the following bits of functionality," and should briefly d= escribe
>the functionality that's needed, and refer to the documents that th= e SDO
>is working on that support this need.
>
>If this need is not really coming from these SDOs, but rather from some=
>IETF working group, then perhaps Bernie's original observation was<= br> >correct, and this work should be done in that working group instead. >
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg

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



--
Best Regards=
Rajat Ghai
CTO
Benu Networks (www.benunets.com)

=
--047d7b4142f8ba6b5e04dab686d1-- From rghai@benunets.com Fri Apr 19 06:17:01 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DB121F95DF for ; Fri, 19 Apr 2013 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8xL8PRw2HJyg for ; Fri, 19 Apr 2013 06:17:00 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 2792921F95DB for ; Fri, 19 Apr 2013 06:16:55 -0700 (PDT) Received: from mail-oa0-f72.google.com ([209.85.219.72]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUXFDx+76QWTfr4NSYE6tarNFj6yPmZ5n@postini.com; Fri, 19 Apr 2013 06:16:56 PDT Received: by mail-oa0-f72.google.com with SMTP id i18so2646110oag.3 for ; Fri, 19 Apr 2013 06:16:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tOqLBB3GVQzGZsmq+5zBWm8+vRXHxpVWFXRPAQHBli4=; b=evKTxeC+cKBf4TtLF986bgoR/WELxZOMweGbUh2chS4rJp9CQYsYXhivdPvTyahlSN MiL4VHBmM/bhMJd8WoHA1rL8sM/3F0RAWXF4RyjEynyFyjbP9PgXcQvr797XpulWApLa ZAPT+HjHdjOkm8NTz1cIKDQMmShBnM/wWDGLu99wY6+isBVwo2C0ieR2U4AVXQGFsjRJ POWutrYKdbluubDvZN9Bo2EdXiGpbmTTDSmMTbGrh/iXa97wDl8ExGh99oB5FvJOogDa 4QaeeaUvBpUlOgiBfzLi0rlsPNUWhkXmSJQJkiDUqDoWNDUBpM3uIiwxNRWYIX38DqN8 hbMw== X-Received: by 10.50.15.166 with SMTP id y6mr9419816igc.83.1366377415078; Fri, 19 Apr 2013 06:16:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.15.166 with SMTP id y6mr9419810igc.83.1366377414997; Fri, 19 Apr 2013 06:16:54 -0700 (PDT) Received: by 10.64.252.195 with HTTP; Fri, 19 Apr 2013 06:16:24 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> Date: Fri, 19 Apr 2013 09:16:24 -0400 Message-ID: From: Rajat Ghai To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=14dae9340d65734aff04dab68868 X-Gm-Message-State: ALoCoQlZg/9Q6rwWfbicniwSynJ1CQbWfB9a4qi7yJJ/o2kZxJIoHjHSMELDf8J4GfIWcLz8kKTJREDSXWzv5Rkmd0E1hrPb7FZwEHeiI+9uk9WSwWf9vbLjuKxyadCJTkSpiU20bffXJElFW7Pba/oLQvJA44wawg== Cc: "dhcwg@ietf.org" , Florin Baboescu , Ted Lemon , Jouni Korhonen , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 13:17:01 -0000 --14dae9340d65734aff04dab68868 Content-Type: text/plain; charset=ISO-8859-1 Tend to agree with Sri here .. Not only this Access-Network-Info be used in the Wi-Fi domain ; but in some cases be further transported to the mobile packet core (EPC) in case the user happens to be registered user of a mobile operator and the IP address is eventually allocated from the EPC. Current definition of Option 82 is not enough to carry all the required information. Rajat Ghai CTO Benu Networks On Wed, Apr 17, 2013 at 11:47 AM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Hi Ted, > > Thanks for your comments. > > This requirement is not coming from any SDO. We believe this is a generic > requirement for IETF based IP architectures. > > As you are aware, many operators are deploying large scale SP WiFI > networks. These deployments are based on standard IETF protocols and > architectures (tunneling, mobility, Routing, AAA protocols ...). In many > of these deployments the subscriber services are tied to the access > network, for example, the initial portal page may be different based on > the user location (SSID, AP Mac address ..). These parameters are > typically carried on DHCP option-82, and are coded in a vendor basis. > There is no standard encoding that a backend system can reliably depend on > for learning these parameters. In the past when WiFI was largely contained > to enterprises, with single vendor solutions, this worked fine. But, now > in many deployments there are multi-vendor systems and interop is > required. The draft is trying to attempt to fix that gap. We want to drive > this work in DHC, not using a liaison statement, but as a gap in IETF > protocols, to solve a practical deployment issue and improve > interoperability. > > I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI > networks and he can comment on this. > > > > > Regards > Sri > > > > > > > > > > > > On 4/17/13 7:59 AM, "Ted Lemon" wrote: > > >When we talked about this earlier, I said that it might be better to have > >this work done in DHC rather than forcing it to find a new working group > >because it seemed to be something that was being asked for by other SDOs. > > However, the authors never said anything about that over and above what > >they've already said in meetings, so I don't actually have a clear > >picture of who is asking for this. Looking in the data tracker, I don't > >find any liaison statement requesting that this work be done. > > > >The authors have expressed a great deal of urgency about this work, and I > >don't want to delay it any further, so I will state that as a > >participant, I'm in favor of the working group taking on the work. > >However, with my AD hat on, I would like to get some kind of actual > >request for help from the SDOs who want this functionality before the end > >of the call for adoption. Otherwise I think Bernie's concern that the > >DHC working group really isn't qualified to evaluate the validity of the > >option contents will remain unaddressed, and I think it's a valid concern. > > > >The request from the SDOs should be of the form "we need DHCP options to > >deliver the following bits of functionality," and should briefly describe > >the functionality that's needed, and refer to the documents that the SDO > >is working on that support this need. > > > >If this need is not really coming from these SDOs, but rather from some > >IETF working group, then perhaps Bernie's original observation was > >correct, and this work should be done in that working group instead. > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Best Regards Rajat Ghai CTO Benu Networks (www.benunets.com) --14dae9340d65734aff04dab68868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tend to agree with Sri here .. =A0Not only this Access-Net= work-Info be used in the Wi-Fi domain ; but in some cases be further transp= orted to the mobile packet core (EPC) in case the user happens to be regist= ered user of a mobile operator and the IP address is eventually allocated f= rom the EPC. Current definition of Option 82 is not enough to carry all the= required information.

Rajat Ghai
CTO
Benu Ne= tworks


On Wed, Apr 17, 2013 at 11:47 AM, Sri Gundavelli (sgundave) <sgunda= ve@cisco.com> wrote:
Hi Ted,

Thanks for your comments.

This requirement is not coming from any SDO. We believe this is a generic requirement for IETF based IP architectures.

As you are aware, many operators are deploying large scale SP WiFI
networks. These deployments are based on standard IETF protocols and
architectures (tunneling, mobility, Routing, AAA protocols ...). In many of these deployments the subscriber services are tied to the access
network, for example, the initial portal page may be different based on
the user location (SSID, AP Mac address ..). These parameters are
typically carried on DHCP option-82, and are coded in a vendor basis.
There is no standard encoding that a backend system can reliably depend on<= br> for learning these parameters. In the past when WiFI was largely contained<= br> to enterprises, with single vendor solutions, this worked fine. But, now in many deployments there are multi-vendor systems and interop is
required. The draft is trying to attempt to fix that gap. We want to drive<= br> this work in DHC, not using a liaison statement, but as a gap in IETF
protocols, to solve a practical deployment issue and improve
interoperability.

I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI
networks and he can comment on this.




Regards
Sri











On 4/17/13 7:59 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

>When we talked about this earlier, I said that it might be better to ha= ve
>this work done in DHC rather than forcing it to find a new working grou= p
>because it seemed to be something that was being asked for by other SDO= s.
> =A0However, the authors never said anything about that over and above = what
>they've already said in meetings, so I don't actually have a cl= ear
>picture of who is asking for this. =A0 Looking in the data tracker, I d= on't
>find any liaison statement requesting that this work be done.
>
>The authors have expressed a great deal of urgency about this work, and= I
>don't want to delay it any further, so I will state that as a
>participant, I'm in favor of the working group taking on the work.<= br> >However, with my AD hat on, I would like to get some kind of actual
>request for help from the SDOs who want this functionality before the e= nd
>of the call for adoption. =A0 Otherwise I think Bernie's concern th= at the
>DHC working group really isn't qualified to evaluate the validity o= f the
>option contents will remain unaddressed, and I think it's a valid c= oncern.
>
>The request from the SDOs should be of the form "we need DHCP opti= ons to
>deliver the following bits of functionality," and should briefly d= escribe
>the functionality that's needed, and refer to the documents that th= e SDO
>is working on that support this need.
>
>If this need is not really coming from these SDOs, but rather from some=
>IETF working group, then perhaps Bernie's original observation was<= br> >correct, and this work should be done in that working group instead. >
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg

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



--
Best Regards=
Rajat Ghai
CTO
Benu Networks (www.benunets.com)

=
--14dae9340d65734aff04dab68868-- From denghui02@gmail.com Fri Apr 19 06:51:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0C21F95E2 for ; Fri, 19 Apr 2013 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs25LpGDTHDg for ; Fri, 19 Apr 2013 06:51:47 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 89D4121F95DE for ; Fri, 19 Apr 2013 06:51:47 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id b12so2030356qca.32 for ; Fri, 19 Apr 2013 06:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Pqt0SgnzLwZ9+u7jwlx5Ewypw78AqzOKhZjwZI/Ahq4=; b=caRbPiylmAlx/WTNmlrrrKuOwFhwcfxiQewDtAdGsE4uyEhqSv7780Z4fmdJSK4jTD iX7KNlLWrhzCAb1vdBX5mHvMSsP7+7ChpRd1dhiSzmYb5LDQP/L4Iv4TKcZTLP6352eF Nb2Ue3FOrcjQYjQJdmYLqe3WU7pFWxM5A9Rp/dyXVt6c7mlHX7UwqnC91ZscQn1ZlybC qXWmZr0CNzt8G8qxzdM1aVgoIKTg+z6aBag31dhsA9Ox7FPRF/xD0KJwGvr6KZ+/7X8z UqWNrUQKjf6gOcgwW8ysmWsGS6v6fFULaMJ3ig8B8pHBwOt0julXkQ+JJ7AzjgDyUoE6 9KwA== MIME-Version: 1.0 X-Received: by 10.224.183.80 with SMTP id cf16mr13934433qab.67.1366379507041; Fri, 19 Apr 2013 06:51:47 -0700 (PDT) Received: by 10.49.103.134 with HTTP; Fri, 19 Apr 2013 06:51:46 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> Date: Fri, 19 Apr 2013 21:51:46 +0800 Message-ID: From: Hui Deng To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=20cf303b3a01254cef04dab705a0 Cc: "dhcwg@ietf.org" , Florin Baboescu , Ted Lemon , Jouni Korhonen , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 13:51:49 -0000 --20cf303b3a01254cef04dab705a0 Content-Type: text/plain; charset=ISO-8859-1 Hello all, Historically Wifi access network architecture is not standardized in any SDOs, WBA may need to do this, but still not yet ready. I would agree not so many telecom opeartors are really deploying SP Wifi except for chinese operator. Unfortunatelly that is also the reason CAPWAP which is invented by IETF not yet really used by telecom operator today except for chinese operator. Chinese operators have deployed more than millions of Wifi APs to support IETF protocol. Because APs has been deployed by SP are all using the same ESSID like CMCC, AT&T-WIFI. This draft is useful for SP wifi when user login, SP need to identfy which AP this user has been connected with, based on this draft network access information could be carrier back to the gateway (Access Controller). Regarding to review of this draft, I would recommend the real user like SPs could help to review this draft for the user case, for the technical part, maybe DHC expert could help, thanks -Hui 2013/4/17 Sri Gundavelli (sgundave) > Hi Ted, > > Thanks for your comments. > > This requirement is not coming from any SDO. We believe this is a generic > requirement for IETF based IP architectures. > > As you are aware, many operators are deploying large scale SP WiFI > networks. These deployments are based on standard IETF protocols and > architectures (tunneling, mobility, Routing, AAA protocols ...). In many > of these deployments the subscriber services are tied to the access > network, for example, the initial portal page may be different based on > the user location (SSID, AP Mac address ..). These parameters are > typically carried on DHCP option-82, and are coded in a vendor basis. > There is no standard encoding that a backend system can reliably depend on > for learning these parameters. In the past when WiFI was largely contained > to enterprises, with single vendor solutions, this worked fine. But, now > in many deployments there are multi-vendor systems and interop is > required. The draft is trying to attempt to fix that gap. We want to drive > this work in DHC, not using a liaison statement, but as a gap in IETF > protocols, to solve a practical deployment issue and improve > interoperability. > > I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI > networks and he can comment on this. > > > > > Regards > Sri > > > > > > > > > > > > On 4/17/13 7:59 AM, "Ted Lemon" wrote: > > >When we talked about this earlier, I said that it might be better to have > >this work done in DHC rather than forcing it to find a new working group > >because it seemed to be something that was being asked for by other SDOs. > > However, the authors never said anything about that over and above what > >they've already said in meetings, so I don't actually have a clear > >picture of who is asking for this. Looking in the data tracker, I don't > >find any liaison statement requesting that this work be done. > > > >The authors have expressed a great deal of urgency about this work, and I > >don't want to delay it any further, so I will state that as a > >participant, I'm in favor of the working group taking on the work. > >However, with my AD hat on, I would like to get some kind of actual > >request for help from the SDOs who want this functionality before the end > >of the call for adoption. Otherwise I think Bernie's concern that the > >DHC working group really isn't qualified to evaluate the validity of the > >option contents will remain unaddressed, and I think it's a valid concern. > > > >The request from the SDOs should be of the form "we need DHCP options to > >deliver the following bits of functionality," and should briefly describe > >the functionality that's needed, and refer to the documents that the SDO > >is working on that support this need. > > > >If this need is not really coming from these SDOs, but rather from some > >IETF working group, then perhaps Bernie's original observation was > >correct, and this work should be done in that working group instead. > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www.ietf.org/mailman/listinfo/dhcwg > > --20cf303b3a01254cef04dab705a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,
=A0
Historically=A0Wif= i access network architecture is not standardized in any SDOs, WBA may need= to do this, but still not yet ready. I would agree not so many telecom ope= artors are really deploying SP Wifi except=A0for=A0chinese operator. Unfort= unatelly=A0that is also the reason CAPWAP which is invented by IETF not yet= really used by telecom operator today except for chinese operator.=A0Chine= se operators=A0have deployed more than millions of Wifi APs to support IETF= protocol.
=A0
Because APs has been deployed by SP=A0are all=A0using th= e same ESSID like CMCC, AT&T-WIFI. This draft is useful for SP wifi whe= n user login, SP need to identfy which AP this user has been connected with= , based on this draft network access=A0information could be carrier back to= the gateway (Access Controller).=A0
=A0
Regarding to review of this draft, I would recommend the= real user like SPs could help to review this draft for the user case, for = the technical part, maybe DHC expert could help,
=A0
t= hanks
=A0
-Hui


2013/4/17 Sri Gundavelli (sgundave) <sgundave@cisco= .com>
Hi Ted,

Thanks for your comments.

This requirement is not coming from any SDO. We believe this is a generic requirement for IETF based IP architectures.

As you are aware, many operators are deploying large scale SP WiFI
networks. These deployments are based on standard IETF protocols and
architectures (tunneling, mobility, Routing, AAA protocols ...). In many of these deployments the subscriber services are tied to the access
network, for example, the initial portal page may be different based on
the user location (SSID, AP Mac address ..). These parameters are
typically carried on DHCP option-82, and are coded in a vendor basis.
There is no standard encoding that a backend system can reliably depend on<= br> for learning these parameters. In the past when WiFI was largely contained<= br> to enterprises, with single vendor solutions, this worked fine. But, now in many deployments there are multi-vendor systems and interop is
required. The draft is trying to attempt to fix that gap. We want to drive<= br> this work in DHC, not using a liaison statement, but as a gap in IETF
protocols, to solve a practical deployment issue and improve
interoperability.

I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI
networks and he can comment on this.




Regards
Sri











On 4/17/13 7:59 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

>When we talked about this earlier, I said that it might be better to ha= ve
>this work done in DHC rather than forcing it to find a new working grou= p
>because it seemed to be something that was being asked for by other SDO= s.
> =A0However, the authors never said anything about that over and above = what
>they've already said in meetings, so I don't actually have a cl= ear
>picture of who is asking for this. =A0 Looking in the data tracker, I d= on't
>find any liaison statement requesting that this work be done.
>
>The authors have expressed a great deal of urgency about this work, and= I
>don't want to delay it any further, so I will state that as a
>participant, I'm in favor of the working group taking on the work.<= br> >However, with my AD hat on, I would like to get some kind of actual
>request for help from the SDOs who want this functionality before the e= nd
>of the call for adoption. =A0 Otherwise I think Bernie's concern th= at the
>DHC working group really isn't qualified to evaluate the validity o= f the
>option contents will remain unaddressed, and I think it's a valid c= oncern.
>
>The request from the SDOs should be of the form "we need DHCP opti= ons to
>deliver the following bits of functionality," and should briefly d= escribe
>the functionality that's needed, and refer to the documents that th= e SDO
>is working on that support this need.
>
>If this need is not really coming from these SDOs, but rather from some=
>IETF working group, then perhaps Bernie's original observation was<= br> >correct, and this work should be done in that working group instead. >
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


--20cf303b3a01254cef04dab705a0-- From volz@cisco.com Fri Apr 19 06:55:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4F621F95F6 for ; Fri, 19 Apr 2013 06:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87xa6KfDvu20 for ; Fri, 19 Apr 2013 06:55:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CEEC821F95EF for ; Fri, 19 Apr 2013 06:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12482; q=dns/txt; s=iport; t=1366379717; x=1367589317; h=from:to:subject:date:message-id:mime-version; bh=bMfVYk13ZJr2qE9xHhUi6qqBgESkmx8YWMyXehENOG4=; b=RlJ3eQLBQtqF+MR+pQN5ENwDkWVbMBaPzm4KjxGoDEanQSmfSKY7rSWR hlQ1H4b48BvgW67fhjR672mf3hzisEk5y/NeizI5zP+8ySB/TWybCQ4Wm 75Qw3W72aYmve57QK9aGIGZcMA22UmtFParzkKbhAQtv4i1lbeYK5zlkD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAL1LcVGtJV2a/2dsb2JhbABQgkJENrguAYgzgQcWdIIhAQQtQQQZASpWJgEEG4gMDJwGoSiNS4EcLYJxYQOYKo9xgVWBNoIo X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208,217";a="200733218" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 19 Apr 2013 13:55:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3JDtG1x011426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Apr 2013 13:55:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 08:55:16 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Late IPR on draft-ietf-dhc-dhcpv6-radius-opt and draft-ietf-dhc-dhcpv6-prefix-pool-opt Thread-Index: Ac49Aeh2FE/4RLQXSdKPnIe3FYwk5Q== Date: Fri, 19 Apr 2013 13:55:14 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850F2AC@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1850F2ACxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Late IPR on draft-ietf-dhc-dhcpv6-radius-opt and draft-ietf-dhc-dhcpv6-prefix-pool-opt 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 Apr 2013 13:55:19 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1850F2ACxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a formal notice of an IPR policy violation according to rfC3979, se= ction 6.2.1, by Leaf Y. Yeh, regarding the "RADIUS Option for DHCPv6 Relay = Agent" and "Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge = Routers" drafts mentioned in the subject of this message. The working group= chairs or AD are responsible for keeping track of IPR policy violations an= d imposing appropriate sanctions. The nature of the policy violation is that disclosure of IPR that the autho= r of the drafts believed to cover the drafts was made more than 1 year afte= r the publication of the initial individual submissions. Disclosure of IPR = is required of IETF participants, as documented in the Note Well policy, an= d it is required to be done in a timely manner. Please see the text here: http://tools.ietf.org/html/rfc3979#section-6.2 I do not know the full details of the sequence of events, but here is the h= istory from a publication perspective: For draft-ietf-dhc-dhcpv6-radius-opt: * Patent applied for November 8, 2011 (from https://datatracker.ietf.org/ip= r/2052/) * draft-yeh-dhc-dhcpv6-authorization-opt-00 published March 5, 2012 * draft-ietf-dhc-dhcpv6-radius-opt-00 published May 7, 2012 * WGLC passed announced February 25, 2013 * IPR 2052 published April 8, 2013 For draft-ietf-dhc-dhcpv6-prefix-pool-opt: * Patent applied for September 26, 2010 (from https://datatracker.ietf.org/= ipr/2051/) * draft-yeh-dhc-dhcpv6-prefix-pool-opt-00 published April 16, 2011 * draft-ietf-dhc-dhcpv6-prefix-pool-opt-00 published September 10, 2012 * WGLC started March 24, 2013 for 2 weeks, did not pass announced * IPR 2051 published April 8, 2013 The working group was unaware of the IPR at the time of the WGLC. Thus, a W= GLC has been re-issued for draft-ietf-dhc-dhcpv6-radius-opt before it can p= roceed. As draft-ietf-dhc-dhcpv6-prefix-pool-opt did not pass its WGLC, no = action will be taken regarding this document at this time. RFC6701 requires working group chairs and/or ADs to impose sanctions when I= PR policy violations have occurred. RFC6701 provides a list of potential = sanctions up to and including removing authors from drafts and restricting = their ability to post on working group mailing lists for periods of time. The sanction that the chairs and AD have chosen in this case is option d in= section 4 of RFC6701, which is to announce what happened on the mailing li= st. And, we also will re-issue the WGLC for draft-ietf-dhc-dhcpv6-radius-op= t. I would encourage any and all participants in the working group who have an= y thoughts of acquiring IPR on IETF work that they may be doing, or are awa= re of patent applications or similar efforts relating to work they are doin= g, to review BCP79 and RFC6701 to obtain a clear understanding of what is r= equired of you in relation to these efforts. - Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1850F2ACxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a formal notice of an IPR policy violatio= n according to rfC3979, section 6.2.1, by Leaf Y. Yeh, regarding the “= ;RADIUS Option for DHCPv6 Relay Agent” and “Prefix Pool Option = for DHCPv6 Relay Agent on the Provider Edge Routers” drafts mentioned in the subject of this message. The working group chairs = or AD are responsible for keeping track of IPR policy violations and imposi= ng appropriate sanctions.

 

The nature of the policy violation is that disclo= sure of IPR that the author of the drafts believed to cover the drafts was = made more than 1 year after the publication of the initial individual submi= ssions. Disclosure of IPR is required of IETF participants, as documented in the Note Well policy, and it is req= uired to be done in a timely manner. Please see the text here:

 

        &= nbsp;       http://tools.ietf.org/html/rfc3979#section-6.2

 

I do not know the full details of the sequence of= events, but here is the history from a publication perspective:=

 

For draft-ietf-dhc-dhcpv6-radius-opt:<= /p>

• Patent applied for November 8, 2011 (from= https://datatracker.ietf.org/ipr/2052/)

• draft-yeh-dhc-dhcpv6-authorization-opt-00= published March 5, 2012

• draft-ietf-dhc-dhcpv6-radius-opt-00 publi= shed May 7, 2012

• WGLC passed announced February 25, 2013

• IPR 2052 published April 8, 2013

 

For draft-ietf-dhc-dhcpv6-prefix-pool-opt:

• Patent applied for September 26, 2010 (fr= om https://datatracker.ietf.org/ipr/2051/)

• draft-yeh-dhc-dhcpv6-prefix-pool-opt-00 p= ublished April 16, 2011

• draft-ietf-dhc-dhcpv6-prefix-pool-opt-00 = published September 10, 2012

• WGLC started March 24, 2013 for 2 weeks, = did not pass announced

• IPR 2051 published April 8, 2013

 

The working group was unaware of the IPR at the t= ime of the WGLC. Thus, a WGLC has been re-issued for draft-ietf-dhc-dhcpv6-= radius-opt before it can proceed. As draft-ietf-dhc-dhcpv6-prefix-pool-opt = did not pass its WGLC, no action will be taken regarding this document at this time.

 

RFC6701 requires working group chairs and/or ADs = to impose sanctions when IPR policy violations have occurred.   R= FC6701 provides a list of potential sanctions up to and including removing = authors from drafts and restricting their ability to post on working group mailing lists for periods of time.

 

The sanction that the chairs and AD have chosen i= n this case is option d in section 4 of RFC6701, which is to announce what = happened on the mailing list. And, we also will re-issue the WGLC for draft= -ietf-dhc-dhcpv6-radius-opt.

 

I would encourage any and all participants in the= working group who have any thoughts of acquiring IPR on IETF work that the= y may be doing, or are aware of patent applications or similar efforts rela= ting to work they are doing, to review BCP79 and RFC6701 to obtain a clear understanding of what is required of y= ou in relation to these efforts.

 

-       = ;   Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1850F2ACxmbrcdx04ciscoc_-- From volz@cisco.com Fri Apr 19 06:55:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7F21F95FB for ; Fri, 19 Apr 2013 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwEOz83GEZMn for ; Fri, 19 Apr 2013 06:55:24 -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 9BAFD21F95FA for ; Fri, 19 Apr 2013 06:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8706; q=dns/txt; s=iport; t=1366379724; x=1367589324; h=from:to:subject:date:message-id:mime-version; bh=tt8DA/HDKeZOsbhR4JoZxIj/U7czzFkd/0ZdE1kgZgA=; b=aH2gC9tXOy9pUifd0wAjQw19xvPxoqScBwwThss7vlBroG73d8Oqzssr dqaHXR9xWo/6TcCjBE8Xp7BPQzOIlXMJB4Fd3HrgSPGUkvzZNGX8Wre5/ ZYdr668m+Kxo+zREStWbgXR4TO9ZBaY/FDDqlu8F78IbJOfydUAH+DPb+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAL1LcVGtJXG9/2dsb2JhbABQgkJENrguAYgzgQcWdIIhAQQdEF4BKhk9JgEEGwGICwycBqEojmctgnFhA5gqj3GBVYE2gig X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208,217";a="200515055" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 19 Apr 2013 13:55:24 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3JDtO6q030455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Apr 2013 13:55:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 08:55:23 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Re-Issued WG Last Call for draft-ietf-dhc-dhcpv6-radius-opt-11 because of late IPR notice - ends May 2, 2013 Thread-Index: Ac49AKTss8K0LCynSXeC4bR0a0H99Q== Date: Fri, 19 Apr 2013 13:55:23 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850F2B3@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1850F2B3xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Re-Issued WG Last Call for draft-ietf-dhc-dhcpv6-radius-opt-11 because of late IPR notice - ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 13:55:25 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1850F2B3xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: Because of a late IPR notice, we are re-issuing the WG Last Call for draft-= ietf-dhc-dhcpv6-radius-opt-11. This last call will end May 2nd, 2013. However, as this document has already passed WG Last Call, for this Last Ca= ll we are primarily focused on whether the IPR notice changes your position= as to whether the draft should advance. If you have no issues because of t= he IPR, you do not need to respond. If you do have concerns because of the = IPR notice, please let the working group know. For details on the IPR notice, see https://datatracker.ietf.org/ipr/2052/. For the draft, see http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-= opt. I will also send a separate notice, but please note that the obligation to = disclose IPR regarding an IETF document exists as soon as the author knows = a patent application will be filed or intends to file for one, not at the t= ime the patent is issued, and not at some later date when the company decid= es what sort of terms they want to ask for. If the patent is not granted, = or a decision is made on licensing terms, the company can amend the IPR dis= closure. These rules are described in BCP79 and can be referenced through http://www= .ietf.org/ipr/policy.html. In addition, online tools for filing IPR disclo= sures can be found at http://www.ietf.org/ipr/file-disclosure. Finally, ex= isting disclosures can be searched online at https://datatracker.ietf.org/i= pr/search/. - Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1850F2B3xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

Because of a late IPR notice, we are re-issuing the = WG Last Call for draft-ietf-dhc-dhcpv6-radius-opt-11. This last call will e= nd May 2nd, 2013.

 

However, as this document has already passed WG Last= Call, for this Last Call we are primarily focused on whether the IPR notic= e changes your position as to whether the draft should advance. If you have= no issues because of the IPR, you do not need to respond. If you do have concerns because of the IPR notice,= please let the working group know.

 

For details on the IPR notice, see https://datatracker.ietf.org/ipr/2052/.

 

For the draft, see http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt.=

 

I will also send a separate notice, but please note = that the obligation to disclose IPR regarding an IETF document exists as soon= as the author knows a patent application will be filed or intends to file = for one, not at the time the patent is issued, and not at some later da= te when the company decides what sort of terms they want to ask for.  If the patent is not granted, or= a decision is made on licensing terms, the company can amend the IPR discl= osure.

 

These rules are described in BCP79 and can be r= eferenced through http= ://www.ietf.org/ipr/policy.html.  In addition, online tools for&nb= sp;filing IPR disclosures can be found at http://www.ietf.org/ipr/file-disclosure.  Finally, existing disclosures can be searched online at https://datatracker.ietf.org/= ipr/search/.

 

-     &= nbsp;    Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1850F2B3xmbrcdx04ciscoc_-- From volz@cisco.com Fri Apr 19 06:55:37 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E921F9601 for ; Fri, 19 Apr 2013 06:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-CVukwHCh-E for ; Fri, 19 Apr 2013 06:55:35 -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 2B6A921F95FA for ; Fri, 19 Apr 2013 06:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7617; q=dns/txt; s=iport; t=1366379735; x=1367589335; h=from:to:subject:date:message-id:mime-version; bh=gMO/zUz8Qw1UKs22Kl+nAOUx/n0JLuYpCwBaxhM5bQU=; b=RMvFJnL4suNxE3v79M7odC784uSNLQXv2DLRPVtAKzhBGoYnq9LwOqgc qCsnuSGck8h5P++8mbf2FB5LnufP4FE4P3kM48Ib1BZARPA8zn5xl3t9G rUJu5quyeD9fFwaAG1wUm2YnI3OzXwaKQnFlwckWiBAdydIetxe84OtzP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAHVLcVGtJV2d/2dsb2JhbABQgkJENsBigQcWdIIhAQQtQR0BKlYmAQQbAYgLDJwEoSqNSwuBES2CcWEDkzqUYYMLgXM1 X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208,217";a="200717523" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 19 Apr 2013 13:55:34 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3JDtYv8023214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Apr 2013 13:55:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 08:55:34 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IPR Disclosure Requirements - Please READ & NOTE! Thread-Index: Ac49AUGMFJwmSM2iQseU7GFBmoEgNQ== Date: Fri, 19 Apr 2013 13:55:33 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1850F2D0@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1850F2D0xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] IPR Disclosure Requirements - Please READ & NOTE! 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 Apr 2013 13:55:37 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1850F2D0xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A reminder: Please note that the obligation to disclose IPR regarding an IETF document = exists as soon as the author knows a patent application will be filed or in= tends to file for one, not at the time the patent is issued, and not at som= e later date when the company decides what sort of terms they want to ask f= or. If the patent is not granted, or a decision is made on licensing terms= , the company can amend the IPR disclosure. And, here's a resend of an email I sent to the DHC WG Mailing List recently= : The following is a good reminder about the IETF IPR policy that Kathleen Mo= riarty sent to the MILE WG in August 2012. I replaced MILE with DHC: Dear DHC WG: As DHC WG chairs, we would like to minimize or hopefully even eliminate lat= e disclosures relating to documents under consideration within the DHC WG. = Therefore you might see us send "reminder" messages in the future to autho= rs or to the DHC WG email list as a whole, asking people whether they know = of Intellectual Property Rights (IPR) relating to specific documents. In o= rder to comply with IETF processes and avoid unnecessary delays, document a= uthors and contributors to our discussions in the DHC WG are asked to pay c= areful attention to these messages and to reply in a timely fashion. Please note that these messages are only reminders of existing IETF policy,= and we are all bound by that policy even in the absence of such reminder m= essages. Everyone who participates in the Internet Standards Process (whet= her by posting to IETF mailing lists, authoring documents, attending IETF m= eetings, or in other ways) needs to be aware of the IETF rules with regard = to IPR. These rules are described in BCP79 and can be referenced through h= ttp://www.ietf.org/ipr/policy.html. In addition, online tools for filing I= PR disclosures can be found at http://www.ietf.org/ipr/file-disclosure. Fi= nally, existing disclosures can be searched online at https://datatracker.i= etf.org/ipr/search/. Also note that these are personal requirements applying to all IETF partici= pants as individuals, and that these requirements also apply to all partici= pants in the DHC WG. Thanks, Bernie & Tomek (DHC WG Co-chairs) --_000_489D13FBFA9B3E41812EA89F188F018E1850F2D0xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A reminder:

 

Please note that the o= bligation to disclose IPR regarding an IETF document exists as soon as the author knows a patent application will be filed or intend= s to file for one, not at the time the patent is issued, and not at som= e later date when the company decides what sort of terms they want to ask f= or.  If the patent is not granted, or a decision is made on licensing terms, the company can amend the IPR di= sclosure.

 

And, here’s a resend of an email I sent to the= DHC WG Mailing List recently:

 

The following is a good reminder about the IETF IPR = policy that Kathleen Moriarty sent to the MILE WG in August 2012. I replace= d MILE with DHC:

 

Dear DHC WG:

As DHC WG chairs, we would like to minimize or hopef= ully even eliminate late disclosures relating to documents under considerat= ion within the DHC WG.  Therefore you might see us send "reminder= " messages in the future to authors or to the DHC WG email list as a whole, asking people whether they know of Intellect= ual Property Rights (IPR) relating to specific documents.  In order to= comply with IETF processes and avoid unnecessary delays, document authors = and contributors to our discussions in the DHC WG are asked to pay careful attention to these messages and to rep= ly in a timely fashion.

Please note that these messages are only reminders o= f existing IETF policy, and we are all bound by that policy even in the abs= ence of such reminder messages.  Everyone who participates in the Inte= rnet Standards Process (whether by posting to IETF mailing lists, authoring documents, attending IETF meetings, or in= other ways) needs to be aware of the IETF rules with regard to IPR.  = These rules are described in BCP79 and can be referenced through http://www.ietf.org/ipr/pol= icy.html.  In addition, online tools for filing IPR disclosures ca= n be found at http://www.ietf.org/ipr= /file-disclosure.  Finally, existing disclosures can be searched o= nline at https://datatracker.ie= tf.org/ipr/search/.

Also note that these are personal requirements apply= ing to all IETF participants as individuals, and that these requirements al= so apply to all participants in the DHC WG.

Thanks,

Bernie & Tomek

(DHC WG Co-chairs)

 

--_000_489D13FBFA9B3E41812EA89F188F018E1850F2D0xmbrcdx04ciscoc_-- From sarikaya2012@gmail.com Fri Apr 19 08:27:46 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83A21F9603 for ; Fri, 19 Apr 2013 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6rcgbM7KYdi for ; Fri, 19 Apr 2013 08:27:45 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 281A321F95FE for ; Fri, 19 Apr 2013 08:27:44 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id fp13so3614627lab.26 for ; Fri, 19 Apr 2013 08:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=84DM/9BZ7mAgsmUQzuygvoD4P5y/ZO41qcknB5pginU=; b=z/dNl7YkeYq5vL8P8OR4cmrfSOgt638dZZndKGYX4JZytO7m20mmRoVxltX9EDdxP9 by8mnooSZZ0hOpmcK14Ov2Zf3qG4+R4wWue/IsIYTbdBUJkxUi/5YcbXNeD6Rjp9z1SF TfUFzcWXK8hJxWlCWA8jsgPnWlIABjgpZH3sdwhM9wK2Cwn+/aBtYmRRanZSi8lHmvYM x0Vt0lu9Et7Wmzp63gbahzOKehHdl/DXV7SzDA4akX1kutsZ2XInBTx5z3M1wZDfr8PJ Hc4RclAYCZsgjF3/bHvIjaMDzdU+ieCMQhaD4ifl6Ux33Xr4YQ5n3poDe48R1zERPN2i lqkg== MIME-Version: 1.0 X-Received: by 10.112.139.102 with SMTP id qx6mr8178427lbb.99.1366385264074; Fri, 19 Apr 2013 08:27:44 -0700 (PDT) Received: by 10.114.175.140 with HTTP; Fri, 19 Apr 2013 08:27:43 -0700 (PDT) In-Reply-To: References: <8D23D4052ABE7A4490E77B1A012B63077514D333@mbx-01.win.nominum.com> <24C0F3E22276D9438D6F366EB89FAEA810233F0C@xmb-aln-x03.cisco.com> Date: Fri, 19 Apr 2013 10:27:43 -0500 Message-ID: From: Behcet Sarikaya To: Hui Deng Content-Type: multipart/alternative; boundary=089e01182d484aa56c04dab85c89 Cc: "Bernie Volz \(volz\)" , Jouni Korhonen , Ted Lemon , "dhcwg@ietf.org" , Florin Baboescu Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:27:46 -0000 --089e01182d484aa56c04dab85c89 Content-Type: text/plain; charset=ISO-8859-1 Hi Hui, Please see inline. Regards, Behcet On Fri, Apr 19, 2013 at 8:51 AM, Hui Deng wrote: > Hello all, > > Historically Wifi access network architecture is not standardized in any > SDOs, WBA may need to do this, but still not yet ready. I would agree not > so many telecom opeartors are really deploying SP Wifi except for chinese > operator. > There is a new activity in BBF called * Public Wi-Fi Access in Multi-service Broadband Networks *and a document number has been assigned which is very relevant to Wi-Fi access architecture because defining public Wi-Fi access architecture inline with BBF access architecture is part of this activity. Unfortunatelly that is also the reason CAPWAP which is invented by IETF > not yet really used by telecom operator today except for chinese > operator. Chinese operators have deployed more than millions of Wifi APs to > support IETF protocol. > > Because APs has been deployed by SP are all using the same ESSID like > CMCC, AT&T-WIFI. This draft is useful for SP wifi when user login, SP need > to identfy which AP this user has been connected with, based on this draft > network access information could be carrier back to the gateway (Access > Controller). > > Regarding to review of this draft, I would recommend the real user like > SPs could help to review this draft for the user case, for the technical > part, maybe DHC expert could help, > > BBF in the context of new activity should also be considered. --089e01182d484aa56c04dab85c89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hui,

Please see inline.

Regards,

Behcet
On Fri, Apr 19, 2013 at 8:51 AM, Hui Deng <denghui02@= gmail.com> wrote:
Hello all,
= =A0
Historically=A0Wifi access network architecture is not standa= rdized in any SDOs, WBA may need to do this, but still not yet ready. I wou= ld agree not so many telecom opeartors are really deploying SP Wifi except= =A0for=A0chinese operator.

There is a new activity in BBF called =
Pu= blic Wi-Fi Access in Multi-service Broadband Networks

and a document number has been assigned which is= very relevant to Wi-Fi access architecture because defin= ing public Wi-Fi access architecture inline with BBF access architecture is= part of this activity.
Unfortunatelly=A0that is also the reason CA= PWAP which is invented by IETF not yet really used by telecom operator toda= y except for chinese operator.=A0Chinese operators=A0have deployed more tha= n millions of Wifi APs to support IETF protocol.
=A0
Because APs has been deployed by SP=A0are all=A0using th= e same ESSID like CMCC, AT&T-WIFI. This draft is useful for SP wifi whe= n user login, SP need to identfy which AP this user has been connected with= , based on this draft network access=A0information could be carrier back to= the gateway (Access Controller).=A0
=A0
Regarding to review of this draft, I would recommend the= real user like SPs could help to review this draft for the user case, for = the technical part, maybe DHC expert could help,
=A0

BBF in the context of new activity should also be con= sidered.

--089e01182d484aa56c04dab85c89-- From pjhingra@cisco.com Sat Apr 20 00:22:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06DF21F8C35 for ; Sat, 20 Apr 2013 00:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 VHBFhGhmLp17 for ; Sat, 20 Apr 2013 00:22:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 66AE821F89AF for ; Sat, 20 Apr 2013 00:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8895; q=dns/txt; s=iport; t=1366442534; x=1367652134; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ufmCTi5nJIkg83X+8I1p6mvfBHJiJFnl+1h2Obtn0xY=; b=Zvv3Z79m7ZxX6prCIRVgHuaNXOLOVa2sDKjlNC6x6vVksQB5TK35U/UK ssJdBZJCBkCqxtq74hcq0ycPmJaBJa8jH/1N3E7OCl88If0L+EA2cOZ+y xgGYcWj4EBUFBO6XkAj3kDn6iMmIdN4Tx6njEnWUrbSpiuo7/Z4ME6nfL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAJJBclGtJV2Z/2dsb2JhbABQgkJENrhOAYg2gQUWdIIfAQEBBB0QPgMbAgEIEQQBAQsdBzIUCQgBAQQBEgiIDAy9MI1zgQEmEQGCZmEDmDSPcYMMgXM1 X-IronPort-AV: E=Sophos;i="4.87,513,1363132800"; d="scan'208,217";a="200982178" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 20 Apr 2013 07:22:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3K7MDnB030989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Apr 2013 07:22:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sat, 20 Apr 2013 02:22:13 -0500 From: "Prashant Jhingran (pjhingra)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 Thread-Index: Ac47cakbzWTp4LTBSsq8GkSDmdc1YACJX/tg Date: Sat, 20 Apr 2013 07:22:12 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850BFB8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.7] Content-Type: multipart/alternative; boundary="_000_F567B77E0728694BB6716DB3C9000B6B04D196D8xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 07:22:15 -0000 --_000_F567B77E0728694BB6716DB3C9000B6B04D196D8xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor for adoption of this draft. - Regards, Prashant Jhingran NOSTG TME - SP Wi-Fi http://wwwin.cisco.com/ios/tech/mobile/proxyipv6/ http://wwwin.cisco.com/ios/tech/broadband From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, April 17, 2013 7:18 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends May 2,= 2013 Hi all: The author has requested a call for adoption by the WG for draft-lemon-dhc-= topo-conf-01. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that when Ted first published this draft, he posted the following to t= he DHC WG list: I just submitted a new document to the tracker that attempts to document ex= isting practice with respect to how DHCP options are derived and sent to cl= ients in modern DHCP servers. This is a first draft, and probably needs s= ome new examples. People on this mailing list will, I suspect, find it di= fficult to remain awake while reading it because it is such old hat to us, = but it's been brought to my attention recently that not everybody in the IE= TF is an expert on DHCP server configuration; this document is an attempt t= o provide a short, pithy tutorial for IETF document writers who are interes= ted in understanding how DHCP is used in practice. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-lemon-dhc-topo-conf Regards, Tomek & Bernie --_000_F567B77E0728694BB6716DB3C9000B6B04D196D8xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor for adop= tion of this draft.

 

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 7:18 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-lemon-dhc-topo-conf - Ends= May 2, 2013

 

Hi all:

 

The author has requested a call for adoption by t= he WG for draft-lemon-dhc-topo-conf-01.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that when Ted first published this draft, he= posted the following to the DHC WG list:

 

I just submitted a new= document to the tracker that attempts to document existing practice with r= espect to how DHCP options are derived and sent to clients in modern DHCP s= ervers.   This is a first draft, and probably needs some new examples.   People on this mailing list = will, I suspect, find it difficult to remain awake while reading it because= it is such old hat to us, but it's been brought to my attention recently t= hat not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a sho= rt, pithy tutorial for IETF document writers who are interested in understa= nding how DHCP is used in practice.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-lemon-dhc-topo-conf

 

Regards,

Tomek & Bernie

 

--_000_F567B77E0728694BB6716DB3C9000B6B04D196D8xmbrcdx14ciscoc_-- From pjhingra@cisco.com Sat Apr 20 00:23:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAF21F8C69 for ; Sat, 20 Apr 2013 00:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 UH1fbUSfzus2 for ; Sat, 20 Apr 2013 00:23:38 -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 54E1521F8B0A for ; Sat, 20 Apr 2013 00:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7592; q=dns/txt; s=iport; t=1366442618; x=1367652218; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uzSckD7HtOSRckSyDKT3IR7ClJlS9aUoPTj3N58E4tg=; b=agcibpuXLwC1ETLFovA19y8yS/mLlB+X7rl7Ip05MiAnV6W+UF7i6Lx7 WNSNsYNoouylopQ5d1zE+vGYUveYRCtjNW1Mu8SkjOQIGTAPSCu1rTU7s hrbT5fKSdaaijFmPQOc2QvjdngK/fhasOc7CYX6psIaM0lz1fCwS+7dmC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFADtBclGtJV2Y/2dsb2JhbABQgkJENrhOAYg2gQUWdIIfAQEBBB0QXAIBCBEEAQELHQcyFAkIAQEEARIIiAwMvTCNc4EBJhEBgmZhA5g0j3GBVoE2gXM1 X-IronPort-AV: E=Sophos;i="4.87,513,1363132800"; d="scan'208,217";a="200792101" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 20 Apr 2013 07:23:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3K7NbXc031205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Apr 2013 07:23:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 20 Apr 2013 02:23:37 -0500 From: "Prashant Jhingran (pjhingra)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 Thread-Index: Ac47b6ONLSN8YQAvTLWyulsavR6P7gCKE3Dw Date: Sat, 20 Apr 2013 07:23:37 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1850BDF8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.7] Content-Type: multipart/alternative; boundary="_000_F567B77E0728694BB6716DB3C9000B6B04D19736xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 07:23:39 -0000 --_000_F567B77E0728694BB6716DB3C9000B6B04D19736xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor for adoption of this draft. - Regards, Prashant Jhingran NOSTG TME - SP Wi-Fi http://wwwin.cisco.com/ios/tech/mobile/proxyipv6/ http://wwwin.cisco.com/ios/tech/broadband From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, April 17, 2013 7:03 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-ident= ifier-04 - Ends May 2, 2013 Hi all: The authors have requested a call for adoption by the WG for draft-bhandari= -dhc-access-network-identifier-04. This call is being initiated to confirm whether there is WG consensus to ad= opt this work as DHC WG draft. Please state whether or not you're in favor = of the adoption by replying to this mail. If you are not in favor, please a= lso state your objections in your response. This adoption call will complet= e on May 2nd, 2013. Note that the 04 draft was just published and has redesigned options to bet= ter follow the option guidelines. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-bhandari-dhc-access-network-identifier-04. Regards, Tomek & Bernie --_000_F567B77E0728694BB6716DB3C9000B6B04D19736xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor for adop= tion of this draft.

 

 

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 7:03 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-networ= k-identifier-04 - Ends May 2, 2013

 

Hi all:

 

The authors have requested a call for adoption by= the WG for draft-bhandari-dhc-access-network-identifier-04.

 

This call is being initiated to confirm whether t= here is WG consensus to adopt this work as DHC WG draft. Please state wheth= er or not you're in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This adoption call will complete on May = 2nd, 2013.

 

Note that the 04 draft was just published and has= redesigned options to better follow the option guidelines.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04<= /a>.

 

Regards,

Tomek & Bernie

 

--_000_F567B77E0728694BB6716DB3C9000B6B04D19736xmbrcdx14ciscoc_-- From leaf.yeh.sdo@gmail.com Sat Apr 20 03:21:09 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA821F8EB5 for ; Sat, 20 Apr 2013 03:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=2.424, 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 Hce3Y2xFTzzY for ; Sat, 20 Apr 2013 03:21:08 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4943121F8D2C for ; Sat, 20 Apr 2013 03:21:08 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bg4so3670pad.37 for ; Sat, 20 Apr 2013 03:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=d4SiMIMaHzM4GZjMFzpTqbYOQkKkh54aqAq2YSpZFAE=; b=De4o9xy4AuOUuSMqoiPma1LyyF4JwINtH7KvDVYnWnBN1mGKD9IGEBdme4xBDJEIoj rUasuLCfrzLIv93hxB8hsc5CbrnLD0X+o86j0eln62kSpbJ6/7w2pd3Rm42M/YPF+MWW 1q5d7EmbvgUMBWqcAfJqvX9d9AXZPvxHBgMGpVbLUUuTPo+3Iib35MCRhW6/d8vpOcxZ WV3i3BDo7SrpJoAOpTtcy54XageyO8IXEzb5bHrj3aeKYH75oo799eCcL+eLxFe1mCp7 LpAGFotZ2o98iPM0biLMwDv61+1PnOjS9WlnfLKeVfVr/dUE7RZuiDGIq/YlAxuMz6b1 RCIw== X-Received: by 10.68.41.227 with SMTP id i3mr23017831pbl.139.1366453266360; Sat, 20 Apr 2013 03:21:06 -0700 (PDT) Received: from PC ([61.48.185.127]) by mx.google.com with ESMTPS id ih1sm14095041pbb.44.2013.04.20.03.21.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 03:21:05 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , "'Tomek Mrugalski'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com>, <5170b80d.0d43420a.09e7.ffffd707@mx.google.com> In-Reply-To: Date: Sat, 20 Apr 2013 18:20:57 +0800 Message-ID: <51726c11.616f440a.6d8a.6a01@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOPKzovogHcM1pY0u5AcHSatDsXpjdde7ngADwO1A= Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Ted Lemon' Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:21:09 -0000 The OPTION_RELAY_ID defined in RFC 5460 employs the DUID, which is associated with the hardware (or link-layer) address, time of generation or assigned to the DU at the time of manufacture, and has 3 formats (type 1-LTT, 2-EN, 3-LL) defined in RFC3315. These DUIDs sounds not easy to collect beforehand & unfriendly to read by the administrator, who need that to configure the binding relation with the prefix pools on the server for the right prefix delegation (or assignment). Let's go back to the basic relay case of DHCPv6-PD without the mechanism introduced in this draft (OPTION_PREFIX_POOL), how to assign a prefix from a particular pool to the CE? I suppose the basic relay case has the same problem of the uniqueness. GUA(+interface-id) of relay sounds much easy & readable than DUID(+interface-id). Otherwise, could we update the format of OPTION_RELAY_ID defined in RFC5460 to be: 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_RELAY_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . relay-ID . . (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RELAY_ID. option-len Length of DUID in octets. relay-ID An opaque value of arbitrary length configured by the relay agent. which sounds the same requirement on the administrative uniqueness as that of interface-id, but keep the interface-id to only have significance to the relay itself. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, April 19, 2013 8:16 PM To: Leaf Yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Yes, using relay-id should solve the problem of uniquess. Lacking that, perhaps GUA can be used but is not as good. Server does not echo back relay-id unless Relay asked it to using the ERO. - Bernie On Apr 18, 2013, at 11:20 PM, "Leaf Yeh" wrote: > BV> The interface id option can not be used to identify the relay. > BV> There is > no requirement that the interface id is globally unique - it only has > significance to the relay itself. > > If we decide to come back & comply with the exact language of IETF > defined before, how about to update the text in section 5 to be > > "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, > 53) or Interface ID option (OPTION_INTERFACE_ID, 18) so that the > server can identify the relay agent itself or its particular > customer-facing interface with which the prefix pool is associated, if > the server can not use the link-address field specified in the > encapsulation of the DHCPv6 RELAY-FORW message to identify the > interface of the link on which the clients are located." > > and the text in section 6 to be > > "The server MAY use the link-address specified in RELAY-FORW message > to identify the relay agent itself and its particular customer-facing > interface where the prefix pool is associated, but the server has to > maintain the binding data of prefix pools in association with these > link-addresses. To be more readable, the server can alternatively use > Relay-ID and Interface-ID option included in the RELAY-FORW message by > the relay agent to identify the relay agent itself and its particular > customer-facing interface where the prefix pool is associated. In > order to give a meaningful reply, the server has to maintain the > binding data of prefix pools in association with these Relay-ID and > Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD copy > the Interface-ID option from the RELAY-FORW message into the RELAY-REPL message." > > > Does the server need to copy Relay-ID from the RELAY-FORW into the > RELAY-REPL? > > > Best Regards, > Leaf > > PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly. > > > > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Wednesday, April 17, 2013 7:49 PM > To: Leaf Yeh > Cc: Tomek Mrugalski; dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - > Respond by April 8, 2013 > > Fyi - >> To be more readable, the server can alternatively use the Interface >> ID option included in the RELAY-FORW message by the relay agent to >> identify the relay agent itself > > The interface id option can not be used to identify the relay. There > is no requirement that the interface id is globally unique - it only > has significance to the relay itself. > > - Bernie > > On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" wrote: > >> Tomek - How about "Misconfigured or compromised DHCPv6 server can >> cause relays to start announcing arbitrary prefixes, including >> default routes, which could lead to traffic hijack."? >> >> I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't >> bought in the part of 'Compromised DHCPv6 server'. I don't believe >> the ORO option included by the relay could compromise the DHCPv6 server. > Right? >> >> >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >>> "The relay agent SHOULD include the Interface ID option")... >> >> Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: >> "The server MAY use the link-address specified in RELAY-FORW message >> to identify the relay agent itself or its particular customer-facing >> interface where the prefix pool is associated, but the server has to >> maintain the binding data of prefix pools in association with these >> link-addresses. To be more readable, the server can alternatively >> use the Interface ID option included in the RELAY-FORW message by the >> relay agent to identify the relay agent itself or its particular >> customer-facing interface where the prefix pool is associated. In >> order to give a meaningful reply, the server has to maintain the >> binding data of prefix pools in association with the information >> derived from the Interface ID option." >> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for >> both use cases shown in section 3. >> >> >> Tomek -RFC3315: relay MUST include interface-id if the link-address >> in server's response is not sufficient to select downlink interface. >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the >> server can identify the relay itself >> (tomek: that's wrong. Interface-id is for interface or subnet >> identification, not relay identification. Relay-id is used for that >> purpose, see RFC5460, section 5.4.1) >> >> There might be a small debate here. The question could be whether the >> server could identify the relay after receiving the interface-id of >> it. I guess our smart server already support that in the real >> deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 >> (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: >> The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be >> able to use Option 18 in order to retrieve the Access Node identifier >> and access this table in order to identify the ad-hoc pool of >> prefixes or addresses.] >> >> OTOH, I believe relay-id defined in RFC5460 can also be used in the >> case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. >> 2); though if the mechanism of Bulk-Lease-Query is employed, the >> relay also need to include OPTION_ RELAY_ID in the relay-forward >> message for the basic operation of DHCPv6 prefix or address assignment. >> >> >> Tomek - ... if the server would not like to use the link-address >> field specified in RELAY-FORW message >> (tomek: that imprecise or wrong. The server is not at liberty to "not >> use link-address field". There's a specific algorithm defined in >> section 11 of >> RFC3315 that the server must follow it). >> >> Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, >> has the following text: >> " A server selects addresses to be assigned to an IA according to the >> address assignment policies determined by the server administrator >> and the specific information the server determines about the client >> from some combination of the following sources: >> - The link to which the client is attached. ... If the server >> receives the message from a forwarding relay >> agent, then the client is on the same link as the one to which >> the interface, identified by the link-address field in the >> message from the relay agent, is attached... >> - The DUID supplied by the client. >> - Other information in options supplied by the client. >> - Other information in options supplied by the relay agent." >> The above text sounds not put link-address ahead of options supplied >> by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF >> TR-177, its R-07, >> R-08 & section6.6 (...In some deployments there is neither a need nor >> a desire to configure a global or unique local address to the >> interface on which the client messages are received. Such a >> deployment does not allow the BNG to insert an IPv6 address in the >> link-address field...).] >> >> >> Best Regards, >> Leaf >> >> >> >> -----Original Message----- >> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >> Sent: Sunday, April 14, 2013 8:26 PM >> To: Leaf Yeh >> Cc: dhcwg@ietf.org >> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 >> - Respond by April 8, 2013 >> >> On 13-04-12 03:15, Leaf Yeh wrote: >>> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? >>> Your relay will hijack the whole network? ... >>> >>> The relay's behavior is still under control by the server. If it got >>> the wrong configuration, the server could also send out ::/0 in the >>> IA_PD. So this may sound an administration error. We just want the >>> prefix pools not configure to be ::/0 or any overlap between them. I >>> feel a little stuck on the exact text you want. How about 'The >>> administrator of the DHCPv6 server should pay more attention to the >>> configuration of the prefix pools, for examples, a. ::/0 may cause a >>> big routing problem in the whole ISP network; b. the configuration >>> of prefix pool should avoid overlap in the address plan, and etc.' >>> ? I am >> not quite sure... >> Administrator mistake is one concern, the other one is that DHCPv6 >> server may become an attractive attack target when prefix-pool is > deployed. >> >> How about "Misconfigured or compromised DHCPv6 server can cause >> relays to start announcing arbitrary prefixes, including default >> routes, which could lead to traffic hijack."? >> >>> Tomek - Bernie had this concern and I tend to agree with him... the >>> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my >>> reply to Bernie's email. Thanks for your suggestion here. Do we need >>> more explanation on the mathematic function of floor() ? :-) >> I don't think so. A potential implementor who doesn't know what >> floor() function does should probably consider starting a career in >> some other industry. :-) >> >>> Tomek - ...(I know that requestor in most cases is part of a relay, >>> but from protocol perspective these are separate entities)...Yes. >>> Please split actions taken by requestor into separate section. It >>> can be subsection 5.1 if you like to. >>> >>> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the >>> section 5 "Relay Agent Behavior" (just for an editorial change)? Do >>> you want section >>> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? >> Yes to both. >> >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >>> "The relay agent SHOULD include the Interface ID option")... >>> >>> After searching and reading, I still can't find this sentence in RFC3315. >> It is in prefix-pool-opt-02, section 5, second paragraph. Text from >> prefix-pool-opt-02 is an imprecise subset of behaviour described in >> RFC3315, section 20.1.1, second paragraph. Here's the difference: >> >> RFC3315: relay MUST include interface-id if the link-address in >> server's response is not sufficient to select downlink interface. >> >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the >> server can identify the relay itself (tomek: that's wrong. >> Interface-id is for interface or subnet identification, not relay >> identification. Relay-id is used for that purpose, see RFC5460, >> section 5.4.1) if the server would not like to use the link-address >> field > specified in RELAY-FORW message (tomek: >> that imprecise or wrong. The server is not at liberty to "not use >> link-address field". There's a specific algorithm defined in section >> 11 of >> RFC3315 that the server must follow it). >> >> Tomek >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Sat Apr 20 08:15:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9321F8D6A for ; Sat, 20 Apr 2013 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-OjnG4JxiKF for ; Sat, 20 Apr 2013 08:15:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0054321F87B7 for ; Sat, 20 Apr 2013 08:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16937; q=dns/txt; s=iport; t=1366470921; x=1367680521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y0E1bnaFBYyc1uUlgbYejrskU17LTE02kaenLPrzgNk=; b=hC//4e7AAqL+G+UWfvobtjpTlezKOmvpCF02Di2GJd4El0mVW9GXdVnc Y2I+RkATDDqGSrDpIPibQT7X1ESPaj0iMeUJTV5fWh2FLJlgjftrapPam rV2g70zDEe2kYwio3WBfeGR933yNKcWk1JcH8bMMkRkToBkuZJkkw5/UT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAKyvclGtJV2d/2dsb2JhbAA2EAqDBjbBBIEDFnSCHwEBAQMBAQEBNzQEBwUHBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCId6AwkGDC+xTw2JXYxogRUGgQsmBgUHBoJgYQOTRoFrjVoGhRyDDIFzNQ X-IronPort-AV: E=Sophos;i="4.87,513,1363132800"; d="scan'208";a="201037625" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 20 Apr 2013 15:15:20 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3KFFJ40015930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Apr 2013 15:15:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 20 Apr 2013 10:15:19 -0500 From: "Bernie Volz (volz)" To: Leaf Yeh , "'Tomek Mrugalski'" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 Thread-Index: AQHOPbDJp2+XYGGgd0aYVGqbSVclGpjfMk6A Date: Sat, 20 Apr 2013 15:15:19 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1851040B@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com>, <5170b80d.0d43420a.09e7.ffffd707@mx.google.com> <51726c11.616f440a.6d8a.6a01@mx.google.com> In-Reply-To: <51726c11.616f440a.6d8a.6a01@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , 'Ted Lemon' Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 15:15:24 -0000 (WG co-chair hat off.) There are multiple forms of DUID - two of which are not associated with lin= k-layer addresses (DUID-EN and DUID-UUID). Cable Modems have been using the= DUID-LL because that makes it easy as the mac-address has been used for V4= and it is easy enough to map this to the DUID-LL. For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was using= DUID for clients and servers already, so why not relays. The recent propos= al for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC 5460. I don't think we want to "replace" the existing v6 Relay-ID option with alt= ernatives, but that it something that is always up to the WG. I think this = would mean defining a new option as it would be bad to reuse this existing = option for something that is clearly not a DUID (perhaps you can get a new = DUID type defined that allows for an 'opaque' identifier - but I suspect th= at won't be easy as this would lead to the same issues as exist with the DH= CPv4 "client-id" where two people can use the same identifier). Again, if the Interface-ID is unique enough by other standards which would = have to apply when prefix-pool is used, then there is no issue - but this w= ould have to be a clear requirement of using prefix-pool. Personally, I thi= nk this will be missed and is not a good idea. Whatever identifier is used is always problematic as replacing the hardware= will likely require configuring the old identifier into that new hardware = or updating the server's database. Using an address causes similar issues i= f renumbering were to occur. Also, an address may cause problems when there= are multiple relays being used (yes, it is in the peer-address field) but = depending on the 'next hop' destination address used by the relay, it may n= ot be a GUA (the stack may pick a different source address). The Interface-ID (if containing enough to make it 'unique' across devices, = not just within a device) has these same issues - replacing the relay or re= numbering may change the 'interface-id'. I think you should just use the tools presently available (i.e., Relay ID &= Interface ID options) as alternatives are unlikely to have sufficient bene= fits. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Saturday, April 20, 2013 6:21 AM To: Bernie Volz (volz); 'Tomek Mrugalski' Cc: dhcwg@ietf.org; 'Ted Lemon' Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 The OPTION_RELAY_ID defined in RFC 5460 employs the DUID, which is associat= ed with the hardware (or link-layer) address, time of generation or assigne= d to the DU at the time of manufacture, and has 3 formats (type 1-LTT, 2-EN= , 3-LL) defined in RFC3315. These DUIDs sounds not easy to collect beforeha= nd & unfriendly to read by the administrator, who need that to configure th= e binding relation with the prefix pools on the server for the right prefix= delegation (or assignment). Let's go back to the basic relay case of DHCPv6-PD without the mechanism in= troduced in this draft (OPTION_PREFIX_POOL), how to assign a prefix from a = particular pool to the CE? I suppose the basic relay case has the same prob= lem of the uniqueness. GUA(+interface-id) of relay sounds much easy & reada= ble than DUID(+interface-id).=20 Otherwise, could we update the format of OPTION_RELAY_ID defined in RFC5460= to be: 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_RELAY_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . relay-ID . . (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RELAY_ID. option-len Length of DUID in octets. relay-ID An opaque value of arbitrary length configured by the relay agent. which sounds the same requirement on the administrative uniqueness as that = of interface-id, but keep the interface-id to only have significance to the= relay itself.=20 Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, April 19, 2013 8:16 PM To: Leaf Yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Resp= ond by April 8, 2013 Yes, using relay-id should solve the problem of uniquess. Lacking that, per= haps GUA can be used but is not as good.=20 Server does not echo back relay-id unless Relay asked it to using the ERO. - Bernie On Apr 18, 2013, at 11:20 PM, "Leaf Yeh" wrote: > BV> The interface id option can not be used to identify the relay.=20 > BV> There is > no requirement that the interface id is globally unique - it only has=20 > significance to the relay itself. >=20 > If we decide to come back & comply with the exact language of IETF=20 > defined before, how about to update the text in section 5 to be >=20 > "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, > 53) or Interface ID option (OPTION_INTERFACE_ID, 18) so that the=20 > server can identify the relay agent itself or its particular=20 > customer-facing interface with which the prefix pool is associated, if=20 > the server can not use the link-address field specified in the=20 > encapsulation of the DHCPv6 RELAY-FORW message to identify the=20 > interface of the link on which the clients are located." >=20 > and the text in section 6 to be >=20 > "The server MAY use the link-address specified in RELAY-FORW message=20 > to identify the relay agent itself and its particular customer-facing=20 > interface where the prefix pool is associated, but the server has to=20 > maintain the binding data of prefix pools in association with these=20 > link-addresses. To be more readable, the server can alternatively use=20 > Relay-ID and Interface-ID option included in the RELAY-FORW message by=20 > the relay agent to identify the relay agent itself and its particular=20 > customer-facing interface where the prefix pool is associated. In=20 > order to give a meaningful reply, the server has to maintain the=20 > binding data of prefix pools in association with these Relay-ID and=20 > Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD copy=20 > the Interface-ID option from the RELAY-FORW message into the=20 > RELAY-REPL message." >=20 >=20 > Does the server need to copy Relay-ID from the RELAY-FORW into the=20 > RELAY-REPL? >=20 >=20 > Best Regards, > Leaf >=20 > PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly. >=20 >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Wednesday, April 17, 2013 7:49 PM > To: Leaf Yeh > Cc: Tomek Mrugalski; dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 -=20 > Respond by April 8, 2013 >=20 > Fyi - >> To be more readable, the server can alternatively use the Interface=20 >> ID option included in the RELAY-FORW message by the relay agent to=20 >> identify the relay agent itself >=20 > The interface id option can not be used to identify the relay. There=20 > is no requirement that the interface id is globally unique - it only=20 > has significance to the relay itself. >=20 > - Bernie >=20 > On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" wrote: >=20 >> Tomek - How about "Misconfigured or compromised DHCPv6 server can=20 >> cause relays to start announcing arbitrary prefixes, including=20 >> default routes, which could lead to traffic hijack."? >>=20 >> I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't=20 >> bought in the part of 'Compromised DHCPv6 server'. I don't believe=20 >> the ORO option included by the relay could compromise the DHCPv6 server. > Right? >>=20 >>=20 >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g.=20 >>> "The relay agent SHOULD include the Interface ID option")... >>=20 >> Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: >> "The server MAY use the link-address specified in RELAY-FORW message=20 >> to identify the relay agent itself or its particular customer-facing=20 >> interface where the prefix pool is associated, but the server has to=20 >> maintain the binding data of prefix pools in association with these=20 >> link-addresses. To be more readable, the server can alternatively=20 >> use the Interface ID option included in the RELAY-FORW message by the=20 >> relay agent to identify the relay agent itself or its particular=20 >> customer-facing interface where the prefix pool is associated. In=20 >> order to give a meaningful reply, the server has to maintain the=20 >> binding data of prefix pools in association with the information=20 >> derived from the Interface ID option." >> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for=20 >> both use cases shown in section 3. >>=20 >>=20 >> Tomek -RFC3315: relay MUST include interface-id if the link-address=20 >> in server's response is not sufficient to select downlink interface. >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the=20 >> server can identify the relay itself >> (tomek: that's wrong. Interface-id is for interface or subnet=20 >> identification, not relay identification. Relay-id is used for that=20 >> purpose, see RFC5460, section 5.4.1) >>=20 >> There might be a small debate here. The question could be whether the=20 >> server could identify the relay after receiving the interface-id of=20 >> it. I guess our smart server already support that in the real=20 >> deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177=20 >> (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: >> The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be=20 >> able to use Option 18 in order to retrieve the Access Node identifier=20 >> and access this table in order to identify the ad-hoc pool of=20 >> prefixes or addresses.] >>=20 >> OTOH, I believe relay-id defined in RFC5460 can also be used in the=20 >> case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. >> 2); though if the mechanism of Bulk-Lease-Query is employed, the=20 >> relay also need to include OPTION_ RELAY_ID in the relay-forward=20 >> message for the basic operation of DHCPv6 prefix or address assignment. >>=20 >>=20 >> Tomek - ... if the server would not like to use the link-address=20 >> field specified in RELAY-FORW message >> (tomek: that imprecise or wrong. The server is not at liberty to "not=20 >> use link-address field". There's a specific algorithm defined in=20 >> section 11 of >> RFC3315 that the server must follow it). >>=20 >> Section 11 of RFC3315, Selecting Addresses for Assignment to an IA,=20 >> has the following text: >> " A server selects addresses to be assigned to an IA according to the=20 >> address assignment policies determined by the server administrator=20 >> and the specific information the server determines about the client=20 >> from some combination of the following sources: >> - The link to which the client is attached. ... If the server=20 >> receives the message from a forwarding relay >> agent, then the client is on the same link as the one to which >> the interface, identified by the link-address field in the >> message from the relay agent, is attached... >> - The DUID supplied by the client. >> - Other information in options supplied by the client. >> - Other information in options supplied by the relay agent." >> The above text sounds not put link-address ahead of options supplied=20 >> by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF=20 >> TR-177, its R-07, >> R-08 & section6.6 (...In some deployments there is neither a need nor=20 >> a desire to configure a global or unique local address to the=20 >> interface on which the client messages are received. Such a=20 >> deployment does not allow the BNG to insert an IPv6 address in the=20 >> link-address field...).] >>=20 >>=20 >> Best Regards, >> Leaf >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >> Sent: Sunday, April 14, 2013 8:26 PM >> To: Leaf Yeh >> Cc: dhcwg@ietf.org >> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 >> - Respond by April 8, 2013 >>=20 >> On 13-04-12 03:15, Leaf Yeh wrote: >>> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option?=20 >>> Your relay will hijack the whole network? ... >>>=20 >>> The relay's behavior is still under control by the server. If it got=20 >>> the wrong configuration, the server could also send out ::/0 in the=20 >>> IA_PD. So this may sound an administration error. We just want the=20 >>> prefix pools not configure to be ::/0 or any overlap between them. I=20 >>> feel a little stuck on the exact text you want. How about 'The=20 >>> administrator of the DHCPv6 server should pay more attention to the=20 >>> configuration of the prefix pools, for examples, a. ::/0 may cause a=20 >>> big routing problem in the whole ISP network; b. the configuration=20 >>> of prefix pool should avoid overlap in the address plan, and etc.' >>> ? I am >> not quite sure... >> Administrator mistake is one concern, the other one is that DHCPv6=20 >> server may become an attractive attack target when prefix-pool is > deployed. >>=20 >> How about "Misconfigured or compromised DHCPv6 server can cause=20 >> relays to start announcing arbitrary prefixes, including default=20 >> routes, which could lead to traffic hijack."? >>=20 >>> Tomek - Bernie had this concern and I tend to agree with him... the=20 >>> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my=20 >>> reply to Bernie's email. Thanks for your suggestion here. Do we need=20 >>> more explanation on the mathematic function of floor() ? :-) >> I don't think so. A potential implementor who doesn't know what >> floor() function does should probably consider starting a career in=20 >> some other industry. :-) >>=20 >>> Tomek - ...(I know that requestor in most cases is part of a relay,=20 >>> but from protocol perspective these are separate entities)...Yes. >>> Please split actions taken by requestor into separate section. It=20 >>> can be subsection 5.1 if you like to. >>>=20 >>> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the=20 >>> section 5 "Relay Agent Behavior" (just for an editorial change)? Do=20 >>> you want section >>> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? >> Yes to both. >>=20 >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g.=20 >>> "The relay agent SHOULD include the Interface ID option")... >>>=20 >>> After searching and reading, I still can't find this sentence in RFC3315. >> It is in prefix-pool-opt-02, section 5, second paragraph. Text from >> prefix-pool-opt-02 is an imprecise subset of behaviour described in=20 >> RFC3315, section 20.1.1, second paragraph. Here's the difference: >>=20 >> RFC3315: relay MUST include interface-id if the link-address in=20 >> server's response is not sufficient to select downlink interface. >>=20 >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the=20 >> server can identify the relay itself (tomek: that's wrong. >> Interface-id is for interface or subnet identification, not relay=20 >> identification. Relay-id is used for that purpose, see RFC5460,=20 >> section 5.4.1) if the server would not like to use the link-address=20 >> field > specified in RELAY-FORW message (tomek: >> that imprecise or wrong. The server is not at liberty to "not use=20 >> link-address field". There's a specific algorithm defined in section >> 11 of >> RFC3315 that the server must follow it). >>=20 >> Tomek >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Sun Apr 21 08:14:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D9921F84CE for ; Sun, 21 Apr 2013 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.494 X-Spam-Level: ** X-Spam-Status: No, score=2.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 tSZ3VXFP8KIG for ; Sun, 21 Apr 2013 08:14:03 -0700 (PDT) Received: from mail-da0-x22a.google.com (mail-da0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6D06921F841C for ; Sun, 21 Apr 2013 08:14:03 -0700 (PDT) Received: by mail-da0-f42.google.com with SMTP id n15so858442dad.15 for ; Sun, 21 Apr 2013 08:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=zcX7MOAfISSnTFPjrqlvjrezboHVF9M46Yw6Xypdihc=; b=Bs83o42unDNYNyDhxXvafa7RB1KjrsdA1FjbHq8H+od4fdEx2E+6amuYM1mq3DhLGD XlgDbNQ7u2ekgpJqT0LemMBC9bpVu7rEpvb4104f7eUt4ZEcV7jtjRhAknKlza+mmQ/5 5o52ABJnn3z+Ly4Olhawgu74YAuU5x1PIZOtdRNh01UcIYUpxi4bsQ8uHRFQFuxRqbuJ lxkkxhQ1sxn4h8YAgx6OGfeeyvggabulxEXOltYQkPZZ3P1ojffkoolSbYDFTpGnvj2Q OzSXWkR+8rH7Pe9llivkK6jDjRkOrXdbTOmcepn3TflSYE7S/hUcrb5TOcKeziDrujo4 Y2Uw== X-Received: by 10.68.170.3 with SMTP id ai3mr27911359pbc.206.1366557243102; Sun, 21 Apr 2013 08:14:03 -0700 (PDT) Received: from PC ([111.193.201.6]) by mx.google.com with ESMTPS id vb8sm21300469pbc.11.2013.04.21.08.13.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 21 Apr 2013 08:14:02 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" , "'Tomek Mrugalski'" References: <489D13FBFA9B3E41812EA89F188F018E184C093B@xmb-rcd-x04.cisco.com> <5162B8F8.3030908@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513820D@mbx-01.win.nominum.com> <5162C86F.7040104@gmail.com> <5162ff06.e2c4320a.4c2e.4d8e@mx.google.com> <5164156C.7020704@gmail.com> <5167dec6.86f1440a.146b.2032@mx.google.com> <516AA05E.3070801@gmail.com>, <516e825b.ca00450a.3ab2.ffffcbf4@mx.google.com> <4875AA75-E91A-44CB-93FD-077B3C9DB494@cisco.com>, <5170b80d.0d43420a.09e7.ffffd707@mx.google.com> <51726c11.616f440a.6d8a.6a01@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1851040B@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1851040B@xmb-rcd-x04.cisco.com> Date: Sun, 21 Apr 2013 23:13:55 +0800 Message-ID: <5174023a.68ed440a.2a76.5c14@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOPbDJp2+XYGGgd0aYVGqbSVclGpjfMk6AgAF/D4A= Content-Language: zh-cn Cc: dhcwg@ietf.org, 'Ted Lemon' Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 15:14:05 -0000 BV>For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was using DUID for clients and servers already, so why not relays. The recent proposal for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC 5460. Solution A - RFC 5460 may have no problem when relay-id uses DUID, because the server seems only record the relay-id in the process of prefix delegation, not use the relay-id for the client's prefix selecting & assignment. RFC5460 This specification includes a new DHCPv6 option, the Relay-ID option. The option contains a DUID (DHCP Unique Identifier) identifying a DHCPv6 relay agent. Relay agents can include this option in Relay- Forward messages they send. Servers can retain the Relay-ID and associate it with bindings made on behalf of the relay's clients. A relay can then recover binding information about downstream clients by using the Relay-ID in a LEASEQUERY message. BV>Whatever identifier is used is always problematic as replacing the hardware will likely require configuring the old identifier into that new hardware or updating the server's database. Solution B - If GUA of the relay is used for the ID, then configure it into that new hardware, but no need to update this part of the server's database. I meant the IPv6 address plan has no change; the ID of the relay here need be configurable & readable. BV>Using an address causes similar issues if renumbering were to occur. If IPv6 address renumbering of the relay occurs, that sounds the address plan has changed. We need re-configure the binding relationship (GUA of the relay -> prefix Pool) in the server's database. BV>Also, an address may cause problems when there are multiple relays being used (yes, it is in the peer-address field) but depending on the 'next hop' destination address used by the relay, it may not be a GUA (the stack may pick a different source address). I wonder what kind of the ID for relay is used for the basic (or general) case of DHCPv6-PD. GUA sounds a good choice for ID there, but the DUID might not be so popular there. At least RFC3633 has not mentioned it. BV>The Interface-ID (if containing enough to make it 'unique' across devices, not just within a device) has these same issues - replacing the relay or renumbering may change the 'interface-id'. Solution C - If 'syntax' of the interface-id is independent with the hardware of the relay, replacing the relay or (IPv6 address) renumbering the relay may not change the interface-id. If the new & the old relay is the same type, there could be no change in the interface-id; for example, interface-id is only related with the location of the interface. But if you really concern solution C (not a tool presently available ), I would prefer solution B. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Saturday, April 20, 2013 11:15 PM To: Leaf Yeh; 'Tomek Mrugalski' Cc: dhcwg@ietf.org; 'Ted Lemon' Subject: RE: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 (WG co-chair hat off.) There are multiple forms of DUID - two of which are not associated with link-layer addresses (DUID-EN and DUID-UUID). Cable Modems have been using the DUID-LL because that makes it easy as the mac-address has been used for V4 and it is easy enough to map this to the DUID-LL. For RFC 5460, using the DUID seemed like a good approach - DHCPv6 was using DUID for clients and servers already, so why not relays. The recent proposal for DHCPv4 Relay ID (almost out as an RFC) is not as strict as RFC 5460. I don't think we want to "replace" the existing v6 Relay-ID option with alternatives, but that it something that is always up to the WG. I think this would mean defining a new option as it would be bad to reuse this existing option for something that is clearly not a DUID (perhaps you can get a new DUID type defined that allows for an 'opaque' identifier - but I suspect that won't be easy as this would lead to the same issues as exist with the DHCPv4 "client-id" where two people can use the same identifier). Again, if the Interface-ID is unique enough by other standards which would have to apply when prefix-pool is used, then there is no issue - but this would have to be a clear requirement of using prefix-pool. Personally, I think this will be missed and is not a good idea. Whatever identifier is used is always problematic as replacing the hardware will likely require configuring the old identifier into that new hardware or updating the server's database. Using an address causes similar issues if renumbering were to occur. Also, an address may cause problems when there are multiple relays being used (yes, it is in the peer-address field) but depending on the 'next hop' destination address used by the relay, it may not be a GUA (the stack may pick a different source address). The Interface-ID (if containing enough to make it 'unique' across devices, not just within a device) has these same issues - replacing the relay or renumbering may change the 'interface-id'. I think you should just use the tools presently available (i.e., Relay ID & Interface ID options) as alternatives are unlikely to have sufficient benefits. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Saturday, April 20, 2013 6:21 AM To: Bernie Volz (volz); 'Tomek Mrugalski' Cc: dhcwg@ietf.org; 'Ted Lemon' Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 The OPTION_RELAY_ID defined in RFC 5460 employs the DUID, which is associated with the hardware (or link-layer) address, time of generation or assigned to the DU at the time of manufacture, and has 3 formats (type 1-LTT, 2-EN, 3-LL) defined in RFC3315. These DUIDs sounds not easy to collect beforehand & unfriendly to read by the administrator, who need that to configure the binding relation with the prefix pools on the server for the right prefix delegation (or assignment). Let's go back to the basic relay case of DHCPv6-PD without the mechanism introduced in this draft (OPTION_PREFIX_POOL), how to assign a prefix from a particular pool to the CE? I suppose the basic relay case has the same problem of the uniqueness. GUA(+interface-id) of relay sounds much easy & readable than DUID(+interface-id). Otherwise, could we update the format of OPTION_RELAY_ID defined in RFC5460 to be: 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_RELAY_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . relay-ID . . (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RELAY_ID. option-len Length of DUID in octets. relay-ID An opaque value of arbitrary length configured by the relay agent. which sounds the same requirement on the administrative uniqueness as that of interface-id, but keep the interface-id to only have significance to the relay itself. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, April 19, 2013 8:16 PM To: Leaf Yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - Respond by April 8, 2013 Yes, using relay-id should solve the problem of uniquess. Lacking that, perhaps GUA can be used but is not as good. Server does not echo back relay-id unless Relay asked it to using the ERO. - Bernie On Apr 18, 2013, at 11:20 PM, "Leaf Yeh" wrote: > BV> The interface id option can not be used to identify the relay. > BV> There is > no requirement that the interface id is globally unique - it only has > significance to the relay itself. > > If we decide to come back & comply with the exact language of IETF > defined before, how about to update the text in section 5 to be > > "The relay agent SHOULD include the Relay ID option (OPTION_RELAY_ID, > 53) or Interface ID option (OPTION_INTERFACE_ID, 18) so that the > server can identify the relay agent itself or its particular > customer-facing interface with which the prefix pool is associated, if > the server can not use the link-address field specified in the > encapsulation of the DHCPv6 RELAY-FORW message to identify the > interface of the link on which the clients are located." > > and the text in section 6 to be > > "The server MAY use the link-address specified in RELAY-FORW message > to identify the relay agent itself and its particular customer-facing > interface where the prefix pool is associated, but the server has to > maintain the binding data of prefix pools in association with these > link-addresses. To be more readable, the server can alternatively use > Relay-ID and Interface-ID option included in the RELAY-FORW message by > the relay agent to identify the relay agent itself and its particular > customer-facing interface where the prefix pool is associated. In > order to give a meaningful reply, the server has to maintain the > binding data of prefix pools in association with these Relay-ID and > Interface-ID. According to DHCPv6 [RFC3315], the server SHOULD copy > the Interface-ID option from the RELAY-FORW message into the > RELAY-REPL message." > > > Does the server need to copy Relay-ID from the RELAY-FORW into the > RELAY-REPL? > > > Best Regards, > Leaf > > PS. Note that the Fig.1 & 2 in section 3 will be updated accordingly. > > > > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Wednesday, April 17, 2013 7:49 PM > To: Leaf Yeh > Cc: Tomek Mrugalski; dhcwg@ietf.org > Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - > Respond by April 8, 2013 > > Fyi - >> To be more readable, the server can alternatively use the Interface >> ID option included in the RELAY-FORW message by the relay agent to >> identify the relay agent itself > > The interface id option can not be used to identify the relay. There > is no requirement that the interface id is globally unique - it only > has significance to the relay itself. > > - Bernie > > On Apr 17, 2013, at 7:07 AM, "Leaf Yeh" wrote: > >> Tomek - How about "Misconfigured or compromised DHCPv6 server can >> cause relays to start announcing arbitrary prefixes, including >> default routes, which could lead to traffic hijack."? >> >> I agree on the part of 'Mis-Configured DHCPv6 Server', but haven't >> bought in the part of 'Compromised DHCPv6 server'. I don't believe >> the ORO option included by the relay could compromise the DHCPv6 server. > Right? >> >> >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >>> "The relay agent SHOULD include the Interface ID option")... >> >> Section 6 of the draft (OPTION_PREFIX_POOL) has the following text: >> "The server MAY use the link-address specified in RELAY-FORW message >> to identify the relay agent itself or its particular customer-facing >> interface where the prefix pool is associated, but the server has to >> maintain the binding data of prefix pools in association with these >> link-addresses. To be more readable, the server can alternatively >> use the Interface ID option included in the RELAY-FORW message by the >> relay agent to identify the relay agent itself or its particular >> customer-facing interface where the prefix pool is associated. In >> order to give a meaningful reply, the server has to maintain the >> binding data of prefix pools in association with the information >> derived from the Interface ID option." >> The draft (OPTION_PREFIX_POOL) recommends to use interface-id for >> both use cases shown in section 3. >> >> >> Tomek -RFC3315: relay MUST include interface-id if the link-address >> in server's response is not sufficient to select downlink interface. >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the >> server can identify the relay itself >> (tomek: that's wrong. Interface-id is for interface or subnet >> identification, not relay identification. Relay-id is used for that >> purpose, see RFC5460, section 5.4.1) >> >> There might be a small debate here. The question could be whether the >> server could identify the relay after receiving the interface-id of >> it. I guess our smart server already support that in the real >> deployment. [Pls. refer to 'Access Node identifier' in BBF TR-177 >> (http://www.broadband-forum.org/technical/trlist.php ) and its R-30: >> The BNG, when acting as a DHCPv6 Delegating Router or Server, MUST be >> able to use Option 18 in order to retrieve the Access Node identifier >> and access this table in order to identify the ad-hoc pool of >> prefixes or addresses.] >> >> OTOH, I believe relay-id defined in RFC5460 can also be used in the >> case 1 (or Fig. 1) of section 3, but can't be used for case 2 (or Fig. >> 2); though if the mechanism of Bulk-Lease-Query is employed, the >> relay also need to include OPTION_ RELAY_ID in the relay-forward >> message for the basic operation of DHCPv6 prefix or address assignment. >> >> >> Tomek - ... if the server would not like to use the link-address >> field specified in RELAY-FORW message >> (tomek: that imprecise or wrong. The server is not at liberty to "not >> use link-address field". There's a specific algorithm defined in >> section 11 of >> RFC3315 that the server must follow it). >> >> Section 11 of RFC3315, Selecting Addresses for Assignment to an IA, >> has the following text: >> " A server selects addresses to be assigned to an IA according to the >> address assignment policies determined by the server administrator >> and the specific information the server determines about the client >> from some combination of the following sources: >> - The link to which the client is attached. ... If the server >> receives the message from a forwarding relay >> agent, then the client is on the same link as the one to which >> the interface, identified by the link-address field in the >> message from the relay agent, is attached... >> - The DUID supplied by the client. >> - Other information in options supplied by the client. >> - Other information in options supplied by the relay agent." >> The above text sounds not put link-address ahead of options supplied >> by the relay agent. Right? [[Pls. refer to 'Interface-ID' in BBF >> TR-177, its R-07, >> R-08 & section6.6 (...In some deployments there is neither a need nor >> a desire to configure a global or unique local address to the >> interface on which the client messages are received. Such a >> deployment does not allow the BNG to insert an IPv6 address in the >> link-address field...).] >> >> >> Best Regards, >> Leaf >> >> >> >> -----Original Message----- >> From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] >> Sent: Sunday, April 14, 2013 8:26 PM >> To: Leaf Yeh >> Cc: dhcwg@ietf.org >> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 >> - Respond by April 8, 2013 >> >> On 13-04-12 03:15, Leaf Yeh wrote: >>> Tomek - ...What if the server sends out ::/0 in PREFIX_POOL option? >>> Your relay will hijack the whole network? ... >>> >>> The relay's behavior is still under control by the server. If it got >>> the wrong configuration, the server could also send out ::/0 in the >>> IA_PD. So this may sound an administration error. We just want the >>> prefix pools not configure to be ::/0 or any overlap between them. I >>> feel a little stuck on the exact text you want. How about 'The >>> administrator of the DHCPv6 server should pay more attention to the >>> configuration of the prefix pools, for examples, a. ::/0 may cause a >>> big routing problem in the whole ISP network; b. the configuration >>> of prefix pool should avoid overlap in the address plan, and etc.' >>> ? I am >> not quite sure... >> Administrator mistake is one concern, the other one is that DHCPv6 >> server may become an attractive attack target when prefix-pool is > deployed. >> >> How about "Misconfigured or compromised DHCPv6 server can cause >> relays to start announcing arbitrary prefixes, including default >> routes, which could lead to traffic hijack."? >> >>> Tomek - Bernie had this concern and I tend to agree with him... the >>> length of ipv6-prefix should be: floor( (prefix-len + 7)/8 ) See my >>> reply to Bernie's email. Thanks for your suggestion here. Do we need >>> more explanation on the mathematic function of floor() ? :-) >> I don't think so. A potential implementor who doesn't know what >> floor() function does should probably consider starting a career in >> some other industry. :-) >> >>> Tomek - ...(I know that requestor in most cases is part of a relay, >>> but from protocol perspective these are separate entities)...Yes. >>> Please split actions taken by requestor into separate section. It >>> can be subsection 5.1 if you like to. >>> >>> Do you mean add section 5.1 "Leasequery Requestor Behavior" in the >>> section 5 "Relay Agent Behavior" (just for an editorial change)? Do >>> you want section >>> 6.1 "Leasequery Server Behavior" in section 6 "Server Behavior"? >> Yes to both. >> >>> Tomek - ...this draft repeats normative language from RFC3315 (e.g. >>> "The relay agent SHOULD include the Interface ID option")... >>> >>> After searching and reading, I still can't find this sentence in RFC3315. >> It is in prefix-pool-opt-02, section 5, second paragraph. Text from >> prefix-pool-opt-02 is an imprecise subset of behaviour described in >> RFC3315, section 20.1.1, second paragraph. Here's the difference: >> >> RFC3315: relay MUST include interface-id if the link-address in >> server's response is not sufficient to select downlink interface. >> >> prefix-pool-opt-02: relay SHOULD include interface-id, so the the >> server can identify the relay itself (tomek: that's wrong. >> Interface-id is for interface or subnet identification, not relay >> identification. Relay-id is used for that purpose, see RFC5460, >> section 5.4.1) if the server would not like to use the link-address >> field > specified in RELAY-FORW message (tomek: >> that imprecise or wrong. The server is not at liberty to "not use >> link-address field". There's a specific algorithm defined in section >> 11 of >> RFC3315 that the server must follow it). >> >> Tomek >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Sun Apr 21 17:23:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B408F21F869A for ; Sun, 21 Apr 2013 17:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 jVhNbnZbW68C for ; Sun, 21 Apr 2013 17:23:00 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1274521F84F2 for ; Sun, 21 Apr 2013 17:23:00 -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 DSNKUXSC4z/uCYFrLPPNdYrfS96aOmROai+D@postini.com; Sun, 21 Apr 2013 17:23:00 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 907CA1B80EC for ; Sun, 21 Apr 2013 17:22:59 -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 81964190052 for ; Sun, 21 Apr 2013 17:22:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 21 Apr 2013 17:22:59 -0700 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: draft-lemon-dhc-inventory-00 Thread-Index: AQHOPu+KV0EhWMb3jk2QtMYrkGa7CA== Date: Mon, 22 Apr 2013 00:22:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <44BAEABA5D011047B6E5E57481B4FF18@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 00:23:00 -0000 Regular DHC working group members may be amused or perhaps disturbed to lea= rn that I've posted yet another ops doc for the working group. This one do= cuments how enterprises and ISPs can manage their network device inventory = using bar codes on boxes, link-layer addresses, and DUIDs. It might be slightly more controversial than the topology document, because= it actually proposes an update to RFC3315 to clarify the meaning of the te= xt forbidding the DHCP server looking at the contents of DUIDs. This prob= ably ought to be in a separate document, if the working group agrees that t= his is a good idea. Like the topo doc, this is being submitted with my AD hat off=97the reason = I've submitted so many documents lately is because I keep noticing situatio= ns where we all know something, but nobody else in the IETF knows it, and I= think it's worth actually documenting this stuff. Let me know what you think! Thanks! http://tools.ietf.org/html/draft-lemon-dhc-inventory-00 From Ted.Lemon@nominum.com Sun Apr 21 17:51:37 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3C21F8640 for ; Sun, 21 Apr 2013 17:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 6beXSc08ceMr for ; Sun, 21 Apr 2013 17:51:37 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3221F8651 for ; Sun, 21 Apr 2013 17:51:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUXSJmHFk8ve/iplG7/NaNGM0SkXWg13F@postini.com; Sun, 21 Apr 2013 17:51:37 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 A4A9B1B80EC for ; Sun, 21 Apr 2013 17:51:36 -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 9CFE6190052 for ; Sun, 21 Apr 2013 17:51:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 21 Apr 2013 17:51:31 -0700 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOPu+KV0EhWMb3jk2QtMYrkGa7CJjh3oaA Date: Mon, 22 Apr 2013 00:51:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9BC9E1E4C6E2564DB1277B830C83C046@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 00:51:37 -0000 On Apr 21, 2013, at 8:22 PM, Ted Lemon wrote: > http://tools.ietf.org/html/draft-lemon-dhc-inventory-00 I wound up submitting a -01 because I accidentally copied the security cons= iderations section from the topo doc and then forgot to update it. The -0= 1 includes a more relevant and complete security considerations section. http://tools.ietf.org/html/draft-lemon-dhc-inventory-01 From stenc@s-carlsen.dk Sun Apr 21 18:07:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09121F8717 for ; Sun, 21 Apr 2013 18:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bATT9WbpfswV for ; Sun, 21 Apr 2013 18:07:49 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 32E5821F869A for ; Sun, 21 Apr 2013 18:07:49 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 3E2D449D for ; Mon, 22 Apr 2013 03:07:43 +0200 (CEST) Message-ID: <51748D5C.6020502@s-carlsen.dk> Date: Mon, 22 Apr 2013 03:07:40 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------000704010706090005060100" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 01:07:50 -0000 This is a multi-part message in MIME format. --------------000704010706090005060100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think this is insufficient, it only covers the trivial case: " We are assuming in this case that the link-layer address is available to the DHCP server because it and the router are connected to the same physical link, so the link-layer address appears in the packet header of the received Solicit packet." This rules out any case that involves a relay as insolvable? The paper needs to explain how things should work in any case that can be solved in IPv4. On 22/04/13 2:51, Ted Lemon wrote: > On Apr 21, 2013, at 8:22 PM, Ted Lemon wrote: >> http://tools.ietf.org/html/draft-lemon-dhc-inventory-00 > I wound up submitting a -01 because I accidentally copied the security considerations section from the topo doc and then forgot to update it. The -01 includes a more relevant and complete security considerations section. > > http://tools.ietf.org/html/draft-lemon-dhc-inventory-01 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------000704010706090005060100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I think this is insufficient, it only covers the trivial case:

" We are assuming in this case that the link-layer address is available to the DHCP server because it and the router are connected to the same physical link, so the link-layer address appears in the packet header of the received Solicit packet."

This rules out any case that involves a relay as insolvable?

The paper needs to explain how things should work in any case that can be solved in IPv4.


On 22/04/13 2:51, Ted Lemon wrote:
On Apr 21, 2013, at 8:22 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

http://tools.ietf.org/html/draft-lemon-dhc-inventory-00

I wound up submitting a -01 because I accidentally copied the security considerations section from the topo doc and then forgot to update it.   The -01 includes a more relevant and complete security considerations section.

http://tools.ietf.org/html/draft-lemon-dhc-inventory-01

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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------000704010706090005060100-- From Ted.Lemon@nominum.com Sun Apr 21 18:15:45 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAB921F86F4 for ; Sun, 21 Apr 2013 18:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.273 X-Spam-Level: X-Spam-Status: No, score=-106.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 TEd52A3j9UMw for ; Sun, 21 Apr 2013 18:15:44 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7E32821F8644 for ; Sun, 21 Apr 2013 18:15:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUXSPQCLzWulva9pNxzX4ebk5itXyETb5@postini.com; Sun, 21 Apr 2013 18:15:44 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 2490D1B80EC for ; Sun, 21 Apr 2013 18:15:44 -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 1CCE4190052; Sun, 21 Apr 2013 18:15:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 21 Apr 2013 18:15:44 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOPu+KV0EhWMb3jk2QtMYrkGa7CJjh3oaAgAAEhQCAAAI/AA== Date: Mon, 22 Apr 2013 01:15:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155555@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> <51748D5C.6020502@s-carlsen.dk> In-Reply-To: <51748D5C.6020502@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775155555mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 01:15:45 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775155555mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 21, 2013, at 9:07 PM, Sten Carlsen > wrote: This rules out any case that involves a relay as insolvable? Did you read past this point to the following sections where two strategies= for dealing with cases where the client is not on the same link are discus= sed? I guess I didn't make that very explicit; I can update this text to = point to the later sections of the document. --_000_8D23D4052ABE7A4490E77B1A012B630775155555mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4307B5CFEE73654D990741445EB8E468@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 21, 2013, at 9:07 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
This rules out any case that involves a relay as insolvable?

Did you read past this point to the following sections where two strat= egies for dealing with cases where the client is not on the same link are d= iscussed?   I guess I didn't make that very explicit; I can update thi= s text to point to the later sections of the document.

--_000_8D23D4052ABE7A4490E77B1A012B630775155555mbx01winnominum_-- From stenc@s-carlsen.dk Sun Apr 21 19:02:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999EC21F87D5 for ; Sun, 21 Apr 2013 19:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3] 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 tmBBucQuHvTU for ; Sun, 21 Apr 2013 19:02:40 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 56B8321F87D1 for ; Sun, 21 Apr 2013 19:02:40 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 63BE82A60; Mon, 22 Apr 2013 04:02:37 +0200 (CEST) Message-ID: <51749A3C.5000808@s-carlsen.dk> Date: Mon, 22 Apr 2013 04:02:36 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> <51748D5C.6020502@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155555@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775155555@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------070807090000090001070306" Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 02:02:42 -0000 This is a multi-part message in MIME format. --------------070807090000090001070306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I did read through the whole document but missed that case. I found the sentence in third read through, looking for it the two last times. I think it should be described in the same level of detail, specially it should be described exactly which RFCs mandate the relay to forward the link-layer address to the server. I believe that is a very well kept secret in a narrow circuit, it is not common knowledge in the dhcp-users maillist. Other than that , I think it will fill a void, that many have fallen into and will in the future. I am sorry On 22/04/13 3:15, Ted Lemon wrote: > On Apr 21, 2013, at 9:07 PM, Sten Carlsen > wrote: >> This rules out any case that involves a relay as insolvable? > > Did you read past this point to the following sections where two > strategies for dealing with cases where the client is not on the same > link are discussed? I guess I didn't make that very explicit; I can > update this text to point to the later sections of the document. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------070807090000090001070306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I did read through the whole document but missed that case. I found the sentence in third read through, looking for it the two last times.

I think it should be described in the same level of detail, specially it should be described exactly which RFCs mandate the relay to forward the link-layer address to the server. I believe that is a very well kept secret in a narrow circuit, it is not common knowledge in the dhcp-users maillist.

Other than that , I think it will fill a void, that many have fallen into and will in the future.

I am sorry
On 22/04/13 3:15, Ted Lemon wrote:
On Apr 21, 2013, at 9:07 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
This rules out any case that involves a relay as insolvable?

Did you read past this point to the following sections where two strategies for dealing with cases where the client is not on the same link are discussed?   I guess I didn't make that very explicit; I can update this text to point to the later sections of the document.


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------070807090000090001070306-- From niall.oreilly@ucd.ie Mon Apr 22 02:39:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11C121E803A for ; Mon, 22 Apr 2013 02:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZev29cB7BiM for ; Mon, 22 Apr 2013 02:39:28 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B28E921F8C23 for ; Mon, 22 Apr 2013 02:39:26 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t11so6192128wey.34 for ; Mon, 22 Apr 2013 02:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=YnHeZhjWVIB3+3qXEU3yMRBacuMttvaT2NnebH5CGRQ=; b=j2HxdM7/r/TMOlC4Y/o5hxBu5azkzudMZxWdhFoeCIso9BkzMW1mHm53X+sNBnjGqA zLpjW7bu18SjCtJSBq2WcczcFN3WCs53hBnRPdyZ0oCtcMVvZ9w9UTIWOIMY8URXyeh2 09R3WGu6Dlrlio77uVR++wzkhtjUApGGor0gkILuRt7VheK5n7kosfXSBX9KmwoTYpx0 sA3O56MobjIXqe382DBKf81xXCufGZImZNXTIxaH5O4p2ZPqv3ND+dxkhtP6ahCbBn+D U9T5IIf/+nDSTzxtq7CMcpkYw02rgRPqnWsuhBePVf9gaCu/N5Pv30FHN1Yk4+yphaB7 A4MA== X-Received: by 10.180.84.162 with SMTP id a2mr49300709wiz.14.1366623565978; Mon, 22 Apr 2013 02:39:25 -0700 (PDT) Received: from ?IPv6:2001:770:98:202:5ab0:35ff:fea8:d1fa? ([2001:770:98:202:5ab0:35ff:fea8:d1fa]) by mx.google.com with ESMTPS id g9sm20901015wix.1.2013.04.22.02.39.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 02:39:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: "Niall O'Reilly" In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> Date: Mon, 22 Apr 2013 10:39:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl5U1ufa3RXIWQwtV7EvO5nbl3GE2pFnmcNTUmy9EHB0uMWhy7Ast+kBOoGLN/fSInlaU/9 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 09:39:29 -0000 On 22 Apr 2013, at 01:22, Ted Lemon wrote: > this is being submitted with my AD hat off=97the reason I've submitted = so many documents lately is because I keep noticing situations where we = all know something, but nobody else in the IETF knows it, and I think = it's worth actually documenting this stuff. Absolutely. For me, MUST is too strong in the passage > 2. General Mechanism >=20 > This mechanism takes as its input two pieces of information: one of > the link-layer addresses of a device, and the DUID of the device. = If > the DUID is known, the link-layer address MUST be ignored. If the > DUID is unknown, the link-layer address is used to find the the > inventory record for the device, and then the the DUID is added to > the inventory record. This seems to impose a requirement for an upgrade to the inventory system in order to accommodate DUID before any device whose DUID is known can be unpacked. Is this the intention? Best regards, Niall O'Reilly From linux@thehobsons.co.uk Mon Apr 22 05:30:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0A721F8FE9 for ; Mon, 22 Apr 2013 05:30:04 -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 wiRMw0akPor2 for ; Mon, 22 Apr 2013 05:30:04 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id CEEC321F8FD3 for ; Mon, 22 Apr 2013 05:30:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 877CD10401A for ; Mon, 22 Apr 2013 13:30:01 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6mALQin66h4 for ; Mon, 22 Apr 2013 13:30:01 +0100 (BST) Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 1591629EEE for ; Mon, 22 Apr 2013 13:30:00 +0100 (BST) From: "Simon Hobson" To: "dhcwg@ietf.org" Date: Mon, 22 Apr 2013 13:30:02 +0100 X-Priority: 3 X-Mailer: MailForge 3.0 Mac OS X Message-ID: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:30:04 -0000 Niall O'Reilly wrote: > This seems to impose a requirement for an upgrade to the > inventory system in order to accommodate DUID before any > device whose DUID is known can be unpacked. I think upgrades are going to be required anyway. But if the DUID is known, eg by being printed/barcoded on the box, then I think the intention is that you'd enter that directly into the system and bypass the need to identify the device and collect the DUID when it appears on the network. From stenc@s-carlsen.dk Mon Apr 22 05:36:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569CB21F8F6C for ; Mon, 22 Apr 2013 05:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG1DHEAsRUYy for ; Mon, 22 Apr 2013 05:36:53 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id B59AA21F8FA5 for ; Mon, 22 Apr 2013 05:36:52 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fefe:16ca]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 7234331F5 for ; Mon, 22 Apr 2013 14:36:49 +0200 (CEST) Message-ID: <51752EE1.5050309@s-carlsen.dk> Date: Mon, 22 Apr 2013 14:36:49 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> In-Reply-To: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------040705030604060507020307" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:36:54 -0000 This is a multi-part message in MIME format. --------------040705030604060507020307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One other implication of this is that there must be a closer connection between the inventory system and DHCP-server(s). This may be stepping over some departmental lines, I would not have any clue but if so, it might have a larger significance than should be thought. How would this work with SNMP? I am asking because I have no experience with SNMP. I now that has been used at least some places in parallel to both the inventory system and DHCP. Sorry if this is too much OT. On 22/04/13 14:30, Simon Hobson wrote: > Niall O'Reilly wrote: >> This seems to impose a requirement for an upgrade to the >> inventory system in order to accommodate DUID before any >> device whose DUID is known can be unpacked. > I think upgrades are going to be required anyway. > But if the DUID is known, eg by being printed/barcoded on the box, then I think the intention is that you'd enter that directly into the system and bypass the need to identify the device and collect the DUID when it appears on the network. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------040705030604060507020307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One other implication of this is that there must be a closer connection between the inventory system and DHCP-server(s).

This may be stepping over some departmental lines, I would not have any clue but if so, it might have a larger significance than should be thought.

How would this work with SNMP? I am asking because I have no experience with SNMP. I now that has been used at least some places in parallel to both the inventory system and DHCP. Sorry if this is too much OT.

On 22/04/13 14:30, Simon Hobson wrote:
Niall O'Reilly wrote:

	This seems to impose a requirement for an upgrade to the
	inventory system in order to accommodate DUID before any
	device whose DUID is known can be unpacked.

I think upgrades are going to be required anyway.
But if the DUID is known, eg by being printed/barcoded on the box, then I think the intention is that you'd enter that directly into the system and bypass the need to identify the device and collect the DUID when it appears on the network.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------040705030604060507020307-- From Ted.Lemon@nominum.com Mon Apr 22 05:50:02 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1547421F8EF7 for ; Mon, 22 Apr 2013 05:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.338 X-Spam-Level: X-Spam-Status: No, score=-106.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 SqA4CPkqfcWa for ; Mon, 22 Apr 2013 05:49:54 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9893F21F8F03 for ; Mon, 22 Apr 2013 05:49:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUXUx8Rj822UxRqcTNvuW12GCPaJSUhER@postini.com; Mon, 22 Apr 2013 05:49:53 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 131A81B8144 for ; Mon, 22 Apr 2013 05:49:53 -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 0A97B190052; Mon, 22 Apr 2013 05:49:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 05:49:47 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOPu+KV0EhWMb3jk2QtMYrkGa7CJjh3oaAgAAEhQCAAAI/AIAADRoAgAC00QA= Date: Mon, 22 Apr 2013 12:49:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155A14@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> <51748D5C.6020502@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155555@mbx-01.win.nominum.com> <51749A3C.5000808@s-carlsen.dk> In-Reply-To: <51749A3C.5000808@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775155A14mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:50:03 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775155A14mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 21, 2013, at 10:02 PM, Sten Carlsen > wrote: I think it should be described in the same level of detail, specially it sh= ould be described exactly which RFCs mandate the relay to forward the link-= layer address to the server. I believe that is a very well kept secret in a= narrow circuit, it is not common knowledge in the dhcp-users maillist. Okay, fair enough. I've added this in the middle of the discussion: We are assuming in this section that the link-layer address is available to the DHCP server because it and the router are connected to the same physical link, so the link-layer address appears in the packet header of the received Solicit packet. In cases where the DHCP client is not on the same link as the DHCP server, the server must obtain the link-layer address using the techniques described in Sections and . I'll think about whether I can add anything, but if you have a clear idea o= f what to add, it might be better if you did it--I have limited time to wor= k on this stuff, and only wrote this out because it was practically begging= to pop off the tips of my fingers. --_000_8D23D4052ABE7A4490E77B1A012B630775155A14mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 21, 2013, at 10:02 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
I think it should be described in the same level of detail, specially it sho= uld be described exactly which RFCs mandate the relay to forward the link-l= ayer address to the server. I believe that is a very well kept secret in a = narrow circuit, it is not common knowledge in the dhcp-users maillist.

Okay, fair enough.   I've added this in the middle of the discuss= ion:

        <t>         &nbs= p;                     &n= bsp;                     =                 
          We are assuming in this section tha= t the link-layer address           
          is available to the DHCP server bec= ause it and the router             
          are connected to the same physical = link, so the link-layer            
          address appears in the packet heade= r of the received Solicit          
          packet.  In cases where the DH= CP client is not on the same            
          link as the DHCP server, the server= must obtain the                 &n= bsp; 
          link-layer address using the techni= ques described in                 &= nbsp;
          Sections <xref target=3D"du= id" format=3D"counter"/> and         =           
          <xref target=3D"linklayer&q= uot; format=3D"counter"/>.           =                
        </t>

I'll think about whether I can add anything, but if you have a clear i= dea of what to add, it might be better if you did it--I have limited time t= o work on this stuff, and only wrote this out because it was practically be= gging to pop off the tips of my fingers.

--_000_8D23D4052ABE7A4490E77B1A012B630775155A14mbx01winnominum_-- From Ted.Lemon@nominum.com Mon Apr 22 06:04:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB65B21F8F2F for ; Mon, 22 Apr 2013 06:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 n41RRdN9qBL8 for ; Mon, 22 Apr 2013 06:04:13 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D221F8F1E for ; Mon, 22 Apr 2013 06:04:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUXU1TfzPnqr+ImxEZ1MpDMnW5Npa4nuH@postini.com; Mon, 22 Apr 2013 06:04: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 DF1CA1B8062 for ; Mon, 22 Apr 2013 06:04: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 D723A190052; Mon, 22 Apr 2013 06:04: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.02.0318.004; Mon, 22 Apr 2013 06:04:06 -0700 From: Ted Lemon To: Niall O'Reilly Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOPu+KV0EhWMb3jk2QtMYrkGa7CJjicgMAgAA5MwA= Date: Mon, 22 Apr 2013 13:04:05 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155B7A@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <47BF77E73F937347BE53B3506C72E049@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:04:13 -0000 On Apr 22, 2013, at 5:39 AM, Niall O'Reilly wrote: > This seems to impose a requirement for an upgrade to the > inventory system in order to accommodate DUID before any > device whose DUID is known can be unpacked. >=20 > Is this the intention? Your inventory management system doesn't have to conform to this draft. I= t's just documenting a mechanism for mapping physical inventory to DHCP req= uests. The reason for the MUST is that the DUID is the identifier, not th= e link-layer address, so once you have the DUID in the system, using the li= nk-layer address is (a) superfluous and (b) might cause problems if it chan= ges. From linux@thehobsons.co.uk Mon Apr 22 06:06:41 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C5421F8F9D for ; Mon, 22 Apr 2013 06:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0uabodw6rCs4 for ; Mon, 22 Apr 2013 06:06:41 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 978F821F8F41 for ; Mon, 22 Apr 2013 06:06:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 344C910401A for ; Mon, 22 Apr 2013 14:06:38 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfJyRRw2yzxH for ; Mon, 22 Apr 2013 14:06:38 +0100 (BST) Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id BBF8B29EEE for ; Mon, 22 Apr 2013 14:06:37 +0100 (BST) From: "Simon Hobson" To: dhcwg@ietf.org Date: Mon, 22 Apr 2013 14:06:38 +0100 X-Priority: 3 X-Mailer: MailForge 3.0 Mac OS X Message-ID: <01947BDEEE14A2DFCB204B34EE91D694@thehobsons.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:06:41 -0000 Sten Carlsen wrote: > One other implication of this is that there must be a closer > connection between the inventory system and DHCP-server(s). Indeed, and this has been "well discussed" before - I'm sure you'll remember it over on the DHCP-Users list (as part of a larger discussion). It's a consequence of using an identifier that probably isn't known before powering up the device, and would be the same for a device where the MAC address wasn't externally identified when using IPv4. From niall.oreilly@ucd.ie Mon Apr 22 06:35:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047C321F85DB for ; Mon, 22 Apr 2013 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RiCinY9Nq7v for ; Mon, 22 Apr 2013 06:35:43 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 49F0821F85BF for ; Mon, 22 Apr 2013 06:35:43 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id c10so4397506wiw.6 for ; Mon, 22 Apr 2013 06:35:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer:x-gm-message-state; bh=6LVRxVbKygBpmewtnvtsp8uWPKkTAWPmogUDifqmTXM=; b=QhIfzBkRlBNa1GaYalUlHhhwvkzMlyLSgXxxXXfdPadTUX0+wHN1BeMkmdG1g1xIhn xMuNbdjDldhKMJjSzeSAQiwDJtPnTHosj/a7hS2MTMJx7Q+/RcKuL7w3upG0apXFeMTz KBLvYj5xGRDzh5TGiw9EO5uUWQKhdqZQUkMuEvtJQ70EDX3O7lP3IjC9cmCJownGX0OT 9ccyWc2jdAtVYLCgu9mJAPVe+8YLc/D1BcyVSQXYRdLLfLVJ8Sy3l5lvzBn+U8cdoJHP XsMdRA/7ugqI1z5PyTrWC0d+uaYi+dEu1mHgP11L6DwvSjsji+P4w2ujZ3RD/Mz6GD6o i0DA== X-Received: by 10.180.108.106 with SMTP id hj10mr66898309wib.0.1366637741182; Mon, 22 Apr 2013 06:35:41 -0700 (PDT) Received: from ?IPv6:2001:770:98:202:5ab0:35ff:fea8:d1fa? ([2001:770:98:202:5ab0:35ff:fea8:d1fa]) by mx.google.com with ESMTPSA id j10sm20141543wie.1.2013.04.22.06.35.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 06:35:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: "Niall O'Reilly" X-Priority: 3 In-Reply-To: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> Date: Mon, 22 Apr 2013 14:35:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> To: dhcwg@ietf.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlc69/IzvNpQCkutMFp8DNu2GOgoL2qXWG20o6rd3nmRCLb+/MletKWg3LHheL8COUyuGlE Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:35:44 -0000 On 22 Apr 2013, at 13:30, Simon Hobson wrote: > Niall O'Reilly wrote: >> This seems to impose a requirement for an upgrade to the >> inventory system in order to accommodate DUID before any >> device whose DUID is known can be unpacked. >=20 > I think upgrades are going to be required anyway. No doubt. > But if the DUID is known, eg by being printed/barcoded on the box, = then I think the intention is that you'd enter that directly into the = system and bypass the need to identify the device and collect the DUID = when it appears on the network. This is a gaping non-sequitur. It's not because the DUID can be read on the outside of the box that the system can accept the data. Perhaps I ought to have put BEFORE in capitals. I'ld suggest changing the text in the following way: /If the DUID is known, the link-layer address MUST be = ignored./s/known/known and can be accommodated by the inventory system/ Best regards, Niall O'Reilly From Ted.Lemon@nominum.com Mon Apr 22 06:51:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0167E21F905F for ; Mon, 22 Apr 2013 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.386 X-Spam-Level: X-Spam-Status: No, score=-106.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 D-CO9MvIaa1i for ; Mon, 22 Apr 2013 06:51:30 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id BD08221F9057 for ; Mon, 22 Apr 2013 06:51:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUXVAYRhXrJgv6yQYTb2K6/Y8C2JK2EeW@postini.com; Mon, 22 Apr 2013 06:51:29 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 58CF01B80AE for ; Mon, 22 Apr 2013 06:51:29 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5016F190052; Mon, 22 Apr 2013 06:51:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 06:51:29 -0700 From: Ted Lemon To: Simon Hobson Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOP1UcV0EhWMb3jk2QtMYrkGa7CJjit6aA Date: Mon, 22 Apr 2013 13:51:28 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155DAA@mbx-01.win.nominum.com> References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> In-Reply-To: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6079D6826BB1344D8DD3E700F46750B6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:51:32 -0000 On Apr 22, 2013, at 8:30 AM, Simon Hobson wrote: > But if the DUID is known, eg by being printed/barcoded on the box, then I= think the intention is that you'd enter that directly into the system and = bypass the need to identify the device and collect the DUID when it appears= on the network. Yup, that would eliminate the need for all this complexity. From Ted.Lemon@nominum.com Mon Apr 22 06:54:31 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764321F8200 for ; Mon, 22 Apr 2013 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.41 X-Spam-Level: X-Spam-Status: No, score=-106.41 tagged_above=-999 required=5 tests=[AWL=0.188, 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 WvFEHFdgVW0m for ; Mon, 22 Apr 2013 06:54:02 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A78BC21F905F for ; Mon, 22 Apr 2013 06:53:51 -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 DSNKUXVA7w7IRgmXOI2USH4x2+4oM+eV1GQJ@postini.com; Mon, 22 Apr 2013 06:53: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 4BBFB1B80AE for ; Mon, 22 Apr 2013 06:53: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 43E5F190052; Mon, 22 Apr 2013 06:53:51 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 06:53:51 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOP1UcV0EhWMb3jk2QtMYrkGa7CJjiosyAgAAVg4A= Date: Mon, 22 Apr 2013 13:53:51 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155E14@mbx-01.win.nominum.com> References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> <51752EE1.5050309@s-carlsen.dk> In-Reply-To: <51752EE1.5050309@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775155E14mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:54:32 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775155E14mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 22, 2013, at 8:36 AM, Sten Carlsen > wrote: This may be stepping over some departmental lines, I would not have any clu= e but if so, it might have a larger significance than should be thought. This draft is intended to illustrate how something can be done, not mandate= that it be done, so I think we don't need to worry about this. How would this work with SNMP? I am asking because I have no experience wit= h SNMP. I now that has been used at least some places in parallel to both t= he inventory system and DHCP. Sorry if this is too much OT. I think SNMP is indeed out of scope. We don't have an SNMP MIB for DHCP an= yway, although there are lots of private MIBs floating around out there. = My intention in this draft was to separate out the database functionality f= rom the DHCP server, so that we didn't have to change the DHCP standard. = If it weren't for the update to RFC3315, this would be either BCP or Inform= ational. --_000_8D23D4052ABE7A4490E77B1A012B630775155E14mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1CCA297AD455214B8A7B325F3E9F393D@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 22, 2013, at 8:36 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
This may be stepping over some departmental lines, I would not have any clue bu= t if so, it might have a larger significance than should be thought.=

This draft is intended to illustrate how something can be done, not mandate= that it be done, so I think we don't need to worry about this.

How would this work with SNMP? I am asking because I have no experience with S= NMP. I now that has been used at least some places in parallel to both the = inventory system and DHCP. Sorry if this is too much OT.

I think SNMP is indeed out of scope.  We don't have an SNMP MIB f= or DHCP anyway, although there are lots of private MIBs floating around out= there.   My intention in this draft was to separate out the database = functionality from the DHCP server, so that we didn't have to change the DHCP standard.   If it weren't for the u= pdate to RFC3315, this would be either BCP or Informational.

--_000_8D23D4052ABE7A4490E77B1A012B630775155E14mbx01winnominum_-- From Ted.Lemon@nominum.com Mon Apr 22 06:57:41 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5121E805D for ; Mon, 22 Apr 2013 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.429 X-Spam-Level: X-Spam-Status: No, score=-106.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 jlYa4tNg1-YV for ; Mon, 22 Apr 2013 06:57:39 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 15EB321E8064 for ; Mon, 22 Apr 2013 06:57:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUXVBy340eEiZ+KT8+jNiYG3wdCIzCHnR@postini.com; Mon, 22 Apr 2013 06:57:36 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 AAFBF1B80EF for ; Mon, 22 Apr 2013 06:57:31 -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 51CA3190052; Mon, 22 Apr 2013 06:57:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 06:57:31 -0700 From: Ted Lemon To: Niall O'Reilly Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOP1UcV0EhWMb3jk2QtMYrkGa7CJjiszeAgAAGH4A= Date: Mon, 22 Apr 2013 13:57:31 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775155E75@mbx-01.win.nominum.com> References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:57:41 -0000 On Apr 22, 2013, at 9:35 AM, Niall O'Reilly wrote: > /If the DUID is known, the link-layer address MUST be ignored./s/known/kn= own and can be accommodated by the inventory system/ If it can't be accommodated by the inventory system, you aren't implementin= g the mechanism described in this document. No harm, no foul. This docu= ment just describes a way of solving the problem=97if you prefer a differen= t solution, you are not required to implement this one. From leo.liubing@huawei.com Mon Apr 22 07:35:59 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38121E8089 for ; Mon, 22 Apr 2013 07:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzUhJ1CeFDd0 for ; Mon, 22 Apr 2013 07:35:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBBC221E8051 for ; Mon, 22 Apr 2013 07:35:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASB73760; Mon, 22 Apr 2013 14:35:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Apr 2013 15:35:17 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Apr 2013 15:35:41 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.13]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Mon, 22 Apr 2013 22:35:36 +0800 From: "Liubing (Leo)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHONTP+VrgXH1zuI0aAfYfSLmEAP5jiXSCw Date: Mon, 22 Apr 2013 14:35:36 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6FDE61@nkgeml506-mbx.china.huawei.com> References: <51640E5C.4020900@gmail.com> <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 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 Apr 2013 14:35:59 -0000 I'm in favor of advancing it. Thank the authors for writing this great docu= ment! Just one minor comment, I'm not sure, but just throwing out my idea: We have 22 sections in one document, it might be a little fragmented, so wo= uld it be better to aggregate the specific guidelines into less number of p= rinciples or aspects? So that it might be easier for the readers to underst= and and remember in mind. Cheers, Bing > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bernie Volz (volz) > Sent: Tuesday, April 09, 2013 11:06 PM > To: dhcwg@ietf.org > Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by > April 24 >=20 > Folks, the authors of draft-ietf-dhc-option-guidelines-11, > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's > ready for a WGLC. There's been discussion and comment already, but more > eyes on and a "final" review of this work are required to advance it. >=20 > This document is critical as it provides guidance to others in the IETF > that may not be DHCP "experts" when they need to write a DHCP option > internet-draft. >=20 > At the time of this writing, there is no IPR reported against this draft. >=20 > Please review the draft and indicate whether or not you feel it is ready > to be published. Your response matters to the process, so please do > respond. >=20 > As Tomek is an author, I will evaluate consensus after April 24, 2013. >=20 > Thanks! >=20 > - Bernie >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From niall.oreilly@ucd.ie Mon Apr 22 08:09:27 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8A21F8CF4 for ; Mon, 22 Apr 2013 08:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mNSKDK7yG5X for ; Mon, 22 Apr 2013 08:09:27 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B0C7021F8C0C for ; Mon, 22 Apr 2013 08:09:26 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id e11so978450wgh.0 for ; Mon, 22 Apr 2013 08:09:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=przjz//6M03BcRkzH9V18lMadEC4ILMS9MUx/lHt6J8=; b=aDyfBPl0S/9XI1lq6J+5Oh+w75gNI/BMHtlxxX1r+x43658PVdMmcLxhaoJ4eCT4g0 upNtaOnCMz5YlrSdxdHuOsm3kLIvQrvRbcs6O8GNxMmqAgRZVv6SJ7BjCt32JrfsYoEt U2bHB8JUVxVyoWUmf+Or3geeTNrAuOfRHPDFv2JEd2WlHJ4rMrHOp4u2qpLcJ/1GXkVe ndgglD5CcY7S+NAJqKgCnM9OarChIZbmzt6gQJAksJz723GBdZ1KbGEQlv1/WxTXteRc H9hiZnJzy7U89GnYwwfBlfY8PLr6XDMsJFCc5uCqV/gDKMT2UJdTunZBNjQI+zgMyg/x P7dQ== X-Received: by 10.180.205.135 with SMTP id lg7mr38229955wic.11.1366643364392; Mon, 22 Apr 2013 08:09:24 -0700 (PDT) Received: from ?IPv6:2001:770:98:202:5ab0:35ff:fea8:d1fa? ([2001:770:98:202:5ab0:35ff:fea8:d1fa]) by mx.google.com with ESMTPSA id fp2sm20572783wib.7.2013.04.22.08.09.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 08:09:23 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1085) From: "Niall O'Reilly" In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775155E75@mbx-01.win.nominum.com> Date: Mon, 22 Apr 2013 16:09:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68411010-324C-4C26-A3BB-1F7234E5AA6F@ucd.ie> References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> <8D23D4052ABE7A4490E77B1A012B630775155E75@mbx-01.win.nominum.com> To: dhcwg@ietf.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmoI0o5+tHgZqWsNNwWBRxvO4Rb8EPaXRt8omUyf7eXql8IeEknYkSQP8nEbQQIgCrFpTu9 Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:09:27 -0000 On 22 Apr 2013, at 14:57, Ted Lemon wrote: > If it can't be accommodated by the inventory system, you aren't = implementing the mechanism described in this document. No harm, no = foul. This document just describes a way of solving the problem=97if = you prefer a different solution, you are not required to implement this = one. OK. Some explicit scoping (rather than just the title) might = enhance readability. ATB Niall O'Reilly From stenc@s-carlsen.dk Mon Apr 22 08:52:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF42D21F9223 for ; Mon, 22 Apr 2013 08:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uaJkzY4pzqq for ; Mon, 22 Apr 2013 08:52:43 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF421F9132 for ; Mon, 22 Apr 2013 08:52:42 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (silver3Wired.s-carlsen.dk [192.168.16.103]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id B6BF92A53; Mon, 22 Apr 2013 17:52:38 +0200 (CEST) Message-ID: <51755CC6.2040704@s-carlsen.dk> Date: Mon, 22 Apr 2013 17:52:38 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> <51752EE1.5050309@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155E14@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775155E14@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------010801070008070704050808" Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:52:44 -0000 This is a multi-part message in MIME format. --------------010801070008070704050808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/04/13 15:53, Ted Lemon wrote: > On Apr 22, 2013, at 8:36 AM, Sten Carlsen > wrote: >> This may be stepping over some departmental lines, I would not have >> any clue but if so, it might have a larger significance than should >> be thought. > > This draft is intended to illustrate how something can be done, not > mandate that it be done, so I think we don't need to worry about this. > If in most cases it is very impractical, maybe we should think if there was a different way? I am just trying to be the devil's advocate here but clearly understand that it is "a" method, not "the" method. >> > > I think SNMP is indeed out of scope. Fair enough. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010801070008070704050808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/04/13 15:53, Ted Lemon wrote:
On Apr 22, 2013, at 8:36 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
This may be stepping over some departmental lines, I would not have any clue but if so, it might have a larger significance than should be thought.

This draft is intended to illustrate how something can be done, not mandate that it be done, so I think we don't need to worry about this.

If in most cases it is very impractical, maybe we should think if there was a different way? I am just trying to be the devil's advocate here but clearly understand that it is "a" method, not "the" method.


I think SNMP is indeed out of scope.
Fair enough.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------010801070008070704050808-- From stenc@s-carlsen.dk Mon Apr 22 08:55:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3884F21F9075 for ; Mon, 22 Apr 2013 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFuGcp4bQy3j for ; Mon, 22 Apr 2013 08:55:20 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id D688121F9321 for ; Mon, 22 Apr 2013 08:55:18 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (silver3Wired.s-carlsen.dk [192.168.16.103]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id C58942A53; Mon, 22 Apr 2013 17:55:11 +0200 (CEST) Message-ID: <51755D5F.3000707@s-carlsen.dk> Date: Mon, 22 Apr 2013 17:55:11 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> <51748D5C.6020502@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155555@mbx-01.win.nominum.com> <51749A3C.5000808@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155A14@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775155A14@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------000909000701080602040306" Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:55:21 -0000 This is a multi-part message in MIME format. --------------000909000701080602040306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/04/13 14:49, Ted Lemon wrote: > On Apr 21, 2013, at 10:02 PM, Sten Carlsen > wrote: >> I think it should be described in the same level of detail, specially >> it should be described exactly which RFCs mandate the relay to >> forward the link-layer address to the server. I believe that is a >> very well kept secret in a narrow circuit, it is not common knowledge >> in the dhcp-users maillist. > > Okay, fair enough. I've added this in the middle of the discussion: > > > > We are assuming in this section that the link-layer address > > is available to the DHCP server because it and the router > > are connected to the same physical link, so the link-layer > > address appears in the packet header of the received Solicit > > packet. In cases where the DHCP client is not on the same > > link as the DHCP server, the server must obtain the > > link-layer address using the techniques described in > > Sections and > > . > > > > I'll think about whether I can add anything, but if you have a clear > idea of what to add, it might be better if you did it--I have limited > time to work on this stuff, and only wrote this out because it was > practically begging to pop off the tips of my fingers. This looks fine to me, provided the xrefs become more specific, which I am sure will happen :-) . -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------000909000701080602040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/04/13 14:49, Ted Lemon wrote:
On Apr 21, 2013, at 10:02 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
I think it should be described in the same level of detail, specially it should be described exactly which RFCs mandate the relay to forward the link-layer address to the server. I believe that is a very well kept secret in a narrow circuit, it is not common knowledge in the dhcp-users maillist.

Okay, fair enough.   I've added this in the middle of the discussion:

        <t>                                                                     
          We are assuming in this section that the link-layer address           
          is available to the DHCP server because it and the router             
          are connected to the same physical link, so the link-layer            
          address appears in the packet header of the received Solicit          
          packet.  In cases where the DHCP client is not on the same            
          link as the DHCP server, the server must obtain the                   
          link-layer address using the techniques described in                  
          Sections <xref target="duid" format="counter"/> and                   
          <xref target="linklayer" format="counter"/>.                          
        </t>

I'll think about whether I can add anything, but if you have a clear idea of what to add, it might be better if you did it--I have limited time to work on this stuff, and only wrote this out because it was practically begging to pop off the tips of my fingers.
This looks fine to me, provided the xrefs become more specific, which I am sure will happen :-) .

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------000909000701080602040306-- From Ted.Lemon@nominum.com Mon Apr 22 08:57:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2421F9310 for ; Mon, 22 Apr 2013 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 YIWPuCzonVe4 for ; Mon, 22 Apr 2013 08:57:51 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 352AF21F925B for ; Mon, 22 Apr 2013 08:57:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUXVd/7XRISc5rSH+urJwlfJlU9L/pZBN@postini.com; Mon, 22 Apr 2013 08:57: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 D67971B80A0 for ; Mon, 22 Apr 2013 08:57:50 -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 D040C190052; Mon, 22 Apr 2013 08:57:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 08:57:50 -0700 From: Ted Lemon To: Niall O'Reilly Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOP1UcV0EhWMb3jk2QtMYrkGa7CJjiszeAgAAGH4CAABQUgIAADYkA Date: Mon, 22 Apr 2013 15:57:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775156237@mbx-01.win.nominum.com> References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> <8D23D4052ABE7A4490E77B1A012B630775155E75@mbx-01.win.nominum.com> <68411010-324C-4C26-A3BB-1F7234E5AA6F@ucd.ie> In-Reply-To: <68411010-324C-4C26-A3BB-1F7234E5AA6F@ucd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1275C8D4C8CE9A4899076866B18C73D8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:57:51 -0000 On Apr 22, 2013, at 11:09 AM, Niall O'Reilly wrote: > OK. Some explicit scoping (rather than just the title) might enhance re= adability. Good suggestion=97thanks! From Ted.Lemon@nominum.com Mon Apr 22 09:08:55 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA321F9195 for ; Mon, 22 Apr 2013 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.161, 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 1Me4Bg3QLFRd for ; Mon, 22 Apr 2013 09:08:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8421F918C for ; Mon, 22 Apr 2013 09:08:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUXVglmlDs/E4rIYAHxZF342ICTM7ENfV@postini.com; Mon, 22 Apr 2013 09:08:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 110E91B80A0 for ; Mon, 22 Apr 2013 09:08:54 -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 0AEC5190052; Mon, 22 Apr 2013 09:08:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 09:08:54 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOP1UcV0EhWMb3jk2QtMYrkGa7CJjiosyAgAAVg4CAACEzAIAABIiA Date: Mon, 22 Apr 2013 16:08:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515631F@mbx-01.win.nominum.com> References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> <51752EE1.5050309@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155E14@mbx-01.win.nominum.com> <51755CC6.2040704@s-carlsen.dk> In-Reply-To: <51755CC6.2040704@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B63077515631Fmbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:08:55 -0000 --_000_8D23D4052ABE7A4490E77B1A012B63077515631Fmbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 22, 2013, at 11:52 AM, Sten Carlsen > wrote: If in most cases it is very impractical, maybe we should think if there was= a different way? I am just trying to be the devil's advocate here but clea= rly understand that it is "a" method, not "the" method. I don't think it is impractical; we've heard from some folks who don't want= to implement it, but it's really just describing the mapping technique we = talked about on the mailing list for using the client link-layer address op= tion or the DUID. That seemed to have a lot of support, so I don't think = what's documented here is impractical; indeed, I'm quite certain it would w= ork well. It's probably true that it won't work for everyone, but that's = probably more because they already have a different solution in place than = that this solution wouldn't be a valid way to address their use case. I get the sense that some people are still stuck on the "I don't want to su= pport DUID at all" idea. I don't think that's practical; my expectation i= s that they will eventually cave and do something like what's documented in= this draft. But that's entirely their choice, and if they come up with s= omething that works for them, I have no quarrel at all with that. It will= probably break the protocol, though, so the IETF shouldn't be recommending= it. --_000_8D23D4052ABE7A4490E77B1A012B63077515631Fmbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4E2DF24E4315A24AA58203A0139C1366@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 22, 2013, at 11:52 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
If in most cases it is very impractical, maybe we should think if there was a= different way? I am just trying to be the devil's advocate here but clearl= y understand that it is "a" method, not "the" method.

I don't think it is impractical; we've heard from some folks who don't= want to implement it, but it's really just describing the mapping techniqu= e we talked about on the mailing list for using the client link-layer addre= ss option or the DUID.   That seemed to have a lot of support, so I don't think what's documented here is impra= ctical; indeed, I'm quite certain it would work well.   It's probably = true that it won't work for everyone, but that's probably more because they= already have a different solution in place than that this solution wouldn't be a valid way to address their use= case.

I get the sense that some people are still stuck on the "I don't = want to support DUID at all" idea.   I don't think that's practic= al; my expectation is that they will eventually cave and do something like = what's documented in this draft.   But that's entirely their choice, and if they come up with something that works for them, I ha= ve no quarrel at all with that.   It will probably break the protocol,= though, so the IETF shouldn't be recommending it.

--_000_8D23D4052ABE7A4490E77B1A012B63077515631Fmbx01winnominum_-- From Ted.Lemon@nominum.com Mon Apr 22 09:09:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4921F8D2B for ; Mon, 22 Apr 2013 09:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 hoYXOcmu3pF7 for ; Mon, 22 Apr 2013 09:09:10 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4C21F86D9 for ; Mon, 22 Apr 2013 09:09:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUXVgpr70mEOmCZpmkbzSc0GWo+SmFWgi@postini.com; Mon, 22 Apr 2013 09:09: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 3F4131B8103 for ; Mon, 22 Apr 2013 09:09:10 -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 3895E190052; Mon, 22 Apr 2013 09:09:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 09:09:10 -0700 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] draft-lemon-dhc-inventory-00 Thread-Index: AQHOPu+KV0EhWMb3jk2QtMYrkGa7CJjh3oaAgAAEhQCAAAI/AIAADRoAgAC00QCAADPOgIAAA+YA Date: Mon, 22 Apr 2013 16:09:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775156337@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775155403@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751554A3@mbx-01.win.nominum.com> <51748D5C.6020502@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155555@mbx-01.win.nominum.com> <51749A3C.5000808@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155A14@mbx-01.win.nominum.com> <51755D5F.3000707@s-carlsen.dk> In-Reply-To: <51755D5F.3000707@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775156337mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:09:11 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775156337mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 22, 2013, at 11:55 AM, Sten Carlsen > wrote: This looks fine to me, provided the xrefs become more specific, which I am = sure will happen :-) . xml2rfc should take care of that. :) --_000_8D23D4052ABE7A4490E77B1A012B630775156337mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4F4B1A1113FA1C4EA39FB9076C1142CD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 22, 2013, at 11:55 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
This looks fine to me, provided the xrefs become more specific, which I am sure= will happen  .

xml2rfc should take care of that. :)

--_000_8D23D4052ABE7A4490E77B1A012B630775156337mbx01winnominum_-- From bs7652@att.com Mon Apr 22 09:50:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B238021F93C7; Mon, 22 Apr 2013 09:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOg4oFX-GR8O; Mon, 22 Apr 2013 09:50:03 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7324921F93B4; Mon, 22 Apr 2013 09:50:02 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a3a65715.0.184706.00-346.516791.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 22 Apr 2013 16:50:02 +0000 (UTC) X-MXL-Hash: 51756a3a6ad4ca62-da80a75651f9c77335dec3ee209bde2d8d27c048 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3MGo1I0017563; Mon, 22 Apr 2013 12:50:02 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3MGnqhk017405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 12:49:56 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 22 Apr 2013 16:49:34 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Mon, 22 Apr 2013 12:49:34 -0400 From: "STARK, BARBARA H" To: DHC WG , GEOPRIV WG Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28 Thread-Index: AQHOOR/3p3AxUA+jyUeOnZyfkVodrpjiby4w Date: Mon, 22 Apr 2013 16:49:34 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A9289@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <516AC316.4020005@gmail.com> In-Reply-To: <516AC316.4020005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.173.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Cc+/EsXl c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=lRGdLw0PQukA:10 a=D6pYy_tX0_IA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=uFtKfau1CT4A:10 a=mYPrF8hoAAAA:8 a=46vh5f2oB8hpzY] X-AnalysisOut: [3rO38A:9 a=CjuIK1q_8ugA:10 a=qzXY9qcG92sA:10] Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28 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 Apr 2013 16:50:11 -0000 It would appear to me that this is a solution coming from one particular se= gment of the industry (informative reference is to CableLabs eRouter spec).= I'd like to mention an alternative solution that exists in BBF, for manage= d "RGs", for DHCPv6 options. BBF TR-181 "TR-069 Device:2.6 Root Object definition" (http://www.broadband= -forum.org/cwmp/tr-181-2-6-0.html) is the root object (xml) data model for = TR-069-managed devices. This data model includes, for DHCPv6 server functio= n, the ability to manage the treatment of DHCPv6 options that can get "pass= ed through" from the RG DHCPv6 client to the RG DHCPv6 server. This functio= nality can be managed at a RG DHCPv6 Server Pool level (Device.DHCPv6.Serve= r.Pool.{i}.Option.{i}. object), where it is possible to define different po= ols for different sets of client hosts (allowing different DHCPv6 options a= nd other rules for different sets of client hosts). It is possible to have = a single pool that all client hosts are a member of. The definition and use= of multiple pools is not required, but merely supported by the data model. In this solution, there is no container for passed through options. Rather,= the RG is explicitly configured as to which options to treat this way. The= RG's DHCPv6 client (identified through the "PassthroughClient" parameter, = since it is possible for an RG to have multiple DHCPv6 clients -- due to th= e possibility of multiple WAN interfaces) is expected to request all option= s listed in this DHCPv6 Server Pool Option data model object that have a "P= assthroughClient" identified and make these options available (via the RG D= HCPv6 server) to client hosts that are members of the "pool". The PassthroughClient parameter was not included in the DHCPv4 Server Pool = Option data model object because there were no requests for it. If there we= re demand, the data model could easily be extended to allow similar configu= ration for DHCPv4 options. If the ISP who manages the SP DHCP server wants to configure client hosts, = trusting to the good will of an unmanaged RG (which may or may not support = the container option) may not be the best approach. With that said, if there is demand for standardizing this option container = approach (which I'm ambivalent about), I'll provide the following comments: 1. I recommend using "CE Router" instead of "RG", just to try to get some c= onsistency in terminology used by different WGs and RFCs. 2. Since explicit configuration (as I've described) is a design alternative= , I think it should be mentioned. 3. I would like to see some discussion of the "multiple RG DHCP client" cas= e (caused by multiple WAN interfaces), and recommendations for handling thi= s. 4. As it relates to ecrit/geopriv efforts, RFC 6881 (published by ecrit) ha= s a requirement: AN-14/INT-15: Where a router is employed between a LAN and WAN in a small (less than approximately 650 square meters) area, the router MUST be transparent to the location provided by the WAN to the LAN. This may mean the router must obtain location as a client from the WAN and supply an LCP server to the LAN with the location it obtains. Where the area is larger, the LAN MUST have a location configuration mechanism satisfying the requirements of this document. To me, this suggests that received DHCP location info gets passed through, = one way or another (the LCP [Location Configuration Protocol] server can pr= ovide the location info through various methods) to client hosts. I think i= t's possible for this to occur with or without a specific container that di= rects the router to pass on the location info from its DHCP server function= . Barbara From stenc@s-carlsen.dk Mon Apr 22 10:15:56 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57F211E80C5 for ; Mon, 22 Apr 2013 10:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEKcpvMV7dEG for ; Mon, 22 Apr 2013 10:15:56 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id C994611E80BF for ; Mon, 22 Apr 2013 10:15:55 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fefe:16ca]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 7B82C31F5; Mon, 22 Apr 2013 19:15:53 +0200 (CEST) Message-ID: <51757049.3070301@s-carlsen.dk> Date: Mon, 22 Apr 2013 19:15:53 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <034D54061A071E18B254D11B5195B82F@thehobsons.co.uk> <51752EE1.5050309@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630775155E14@mbx-01.win.nominum.com> <51755CC6.2040704@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B63077515631F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515631F@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------010304070504080906000502" Cc: "" Subject: Re: [dhcwg] draft-lemon-dhc-inventory-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 17:15:56 -0000 This is a multi-part message in MIME format. --------------010304070504080906000502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/04/13 18:08, Ted Lemon wrote: > On Apr 22, 2013, at 11:52 AM, Sten Carlsen > wrote: >> If in most cases it is very impractical, maybe we should think if >> there was a different way? I am just trying to be the devil's >> advocate here but clearly understand that it is "a" method, not "the" >> method. > > I don't think it is impractical; we've heard from some folks who don't > want to implement it, but it's really just describing the mapping > technique we talked about on the mailing list for using the client > link-layer address option or the DUID. That seemed to have a lot of > support, so I don't think what's documented here is impractical; > indeed, I'm quite certain it would work well. It's probably true > that it won't work for everyone, but that's probably more because they > already have a different solution in place than that this solution > wouldn't be a valid way to address their use case. I was thinking of impractical in the sense of administrative / management routines that exist in companies. If too many have issues there, I will still think the solution is impractical. I don't doubt its technical practicality. > > I get the sense that some people are still stuck on the "I don't want > to support DUID at all" idea. I don't think that's practical; my > expectation is that they will eventually cave and do something like > what's documented in this draft. But that's entirely their choice, > and if they come up with something that works for them, I have no > quarrel at all with that. It will probably break the protocol, > though, so the IETF shouldn't be recommending it. The way I read the discussions, most people have accepted that DUID is what you have to use whether you like it or not. At this time I expect that the discussion is more like: How little can we change in our routines and still make this work? I am afraid there is a tendency to underestimate the effort needed to change administrative routines as well as the amount of people that will have to be involved to get it done. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010304070504080906000502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/04/13 18:08, Ted Lemon wrote:
On Apr 22, 2013, at 11:52 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
If in most cases it is very impractical, maybe we should think if there was a different way? I am just trying to be the devil's advocate here but clearly understand that it is "a" method, not "the" method.

I don't think it is impractical; we've heard from some folks who don't want to implement it, but it's really just describing the mapping technique we talked about on the mailing list for using the client link-layer address option or the DUID.   That seemed to have a lot of support, so I don't think what's documented here is impractical; indeed, I'm quite certain it would work well.   It's probably true that it won't work for everyone, but that's probably more because they already have a different solution in place than that this solution wouldn't be a valid way to address their use case.
I was thinking of impractical in the sense of administrative / management routines that exist in companies. If too many have issues there, I will still think the solution is impractical. I don't doubt its technical practicality.

I get the sense that some people are still stuck on the "I don't want to support DUID at all" idea.   I don't think that's practical; my expectation is that they will eventually cave and do something like what's documented in this draft.   But that's entirely their choice, and if they come up with something that works for them, I have no quarrel at all with that.   It will probably break the protocol, though, so the IETF shouldn't be recommending it.
The way I read the discussions, most people have accepted that DUID is what you have to use whether you like it or not. At this time I expect that the discussion is more like: How little can we change in our routines and still make this work? I am afraid there is a tendency to underestimate the effort needed to change administrative routines as well as the amount of people that will have to be involved to get it done.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------010304070504080906000502-- From tomasz.mrugalski@gmail.com Tue Apr 23 04:37:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3167921F971B for ; Tue, 23 Apr 2013 04:37:32 -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 cptfkdk4-QsV for ; Tue, 23 Apr 2013 04:37:31 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id E935421F9711 for ; Tue, 23 Apr 2013 04:37:30 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c4so205671eek.10 for ; Tue, 23 Apr 2013 04:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=/gC9RqFy4kTLuQjL9EOACe7tM+Aq46aXdEpjiueF8Hc=; b=hL+QIDPPYtt/qjdvS0/8Lg+OFPxooTS91cA6gphOXkXqvLezcdu8NlT1d9kJtmtSiv VdVStWU+zACDKS5QD1wKSrOnThlAa1Y6gHk75AMSP3MUTL0YUZawcWNmA9uaiUB4nAi+ Vfat3K5fMelZfWO38QcFp3yzIScyAgZ54BYQCwBNlsKdEkwv/H++OLvpO5ZQVAUSKGCA n2KbCdVb4KOya5majfreHt2rsMh6ul6dq9HUZRV1IADSVWLFfbpAJV4uWJdR+fUQNurb w1u8uAsUvJQNsV9KeHlWUbwiHFoTR36O0uJSTdpkcfYvRMRcF9xBUcUarxyIwCoDC8bV 6hqg== X-Received: by 10.14.223.72 with SMTP id u48mr43646586eep.44.1366717050063; Tue, 23 Apr 2013 04:37:30 -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 d47sm46352657eem.9.2013.04.23.04.37.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 04:37:29 -0700 (PDT) Message-ID: <5176726D.3070709@gmail.com> Date: Tue, 23 Apr 2013 13:37:17 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Last Call: (Reconfigure Triggered by DHCPv6 Relay Agents) to Proposed Standard 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, 23 Apr 2013 11:37:32 -0000 It came to my attention that the current mailing lists configuration did not allow the mail from IESG to go through. I have updated the list configuration, so this should not happen anymore. Although I'm manually re-sending this, I want to make clear that this mail came from IESG, not from me. This draft has passed WGLC couple weeks ago and is now in IETF wide LC. If you have any outstanding comments on it, this is the last time anyone will listen. So speak now or forever hold your peace. Tomek ----- Subject: Last Call: (Reconfigure Triggered by DHCPv6 Relay Agents) to Proposed Standard From: The IESG Date: 22.04.2013 16:15 To: IETF-Announce:; CC: The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Reconfigure Triggered by DHCPv6 Relay Agents' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. This document updates RFC 3315 and RFC 6422. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure/ballot/ No IPR declarations have been submitted directly on this I-D. From tomasz.mrugalski@gmail.com Tue Apr 23 11:33:59 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBC821F973D for ; Tue, 23 Apr 2013 11:33: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 8mNn0sKoytzE for ; Tue, 23 Apr 2013 11:33:58 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 714B821F9728 for ; Tue, 23 Apr 2013 11:33:58 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so400379eek.5 for ; Tue, 23 Apr 2013 11:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:x-forwarded-message-id :content-type:content-transfer-encoding; bh=H7w9mgBp3fz1wiXmRlXhIBR4VNC6w+BiXlqdTGfBbYo=; b=z33pO/TbI+a/OWAvoYt+wobYWFvYYw3jkphRJYyj7CUmdIBEozcuHywATUFmIHR1qL wmjnprST3VPixTUx7PQ4k4ILgPbPn6U5u1A7RiR5gGUGOtMwZuLrm+BDNmAsqRlHfMYr 8TtFReox2c1Mzf1Wp/NkYyl2h4Cc3PrmQ9s+OaPeidErCZ6ar9gLPsRaAQ4oWxhKzjSM cbyGaOCemec1vLqB9OkhKJHWhOV4ukW3ykh6S+HigSufrBfj7tC0BmBlx1P5I6wySApq bcmUb5YzLwXj9+o7/sCPu2Ru2TsNnrvQgYcYYTWKP2vdDqEjRiGIKxrjfgafYkAVjpXl IaMA== X-Received: by 10.14.89.69 with SMTP id b45mr8848466eef.10.1366742037432; Tue, 23 Apr 2013 11:33:57 -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 k43sm21314103een.2.2013.04.23.11.33.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 11:33:56 -0700 (PDT) Message-ID: <5176D408.7020304@gmail.com> Date: Tue, 23 Apr 2013 20:33:44 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg References: <489D13FBFA9B3E41812EA89F188F018E18515058@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18515058@xmb-rcd-x04.cisco.com> X-TagToolbar-Keys: D20130423203344364 X-Forwarded-Message-Id: <489D13FBFA9B3E41812EA89F188F018E18515058@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt 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, 23 Apr 2013 18:33:59 -0000 This mail summarizes Work Group Last Call on draft-ietf-dhc-dhcpv6-prefix-pool-opt announced on March 24th and concluded on April 8th, 2013. Sorry for the late announcement. The chairs feel that this document has failed WGLC as there was insufficient consensus to move forward. This does not mean end of life for this draft - it remains a valid WG item and people are encouraged to work on it. There was also a late IPR disclosure that the working group was not aware of it when the last call started. Existence of IPR claims may have affected the response from WG. Remember that IPR must be disclosed as early as possible (preferably in the individual draft phase). Having said that, there were some good technical comments received. Authors are advised to address them and continue work on this draft. It seems reasonable to focus on a better explanation of why this is a real problem and why the use case is practical rather than theoretical one. But the most important issue here is a lack of support. Please address the comments made in this WGLC, find people who are interested in this work and are ready to voice their support when the time comes and only then ask for another WGLC. Bernie & Tomek From ian.farrer@telekom.de Tue Apr 23 14:23:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94821F91A2 for ; Tue, 23 Apr 2013 14:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 wtQSHLBvM1o8 for ; Tue, 23 Apr 2013 14:23:50 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3334D21F90A1 for ; Tue, 23 Apr 2013 14:23:50 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 23 Apr 2013 23:23:48 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 23 Apr 2013 23:23:48 +0200 From: To: Date: Tue, 23 Apr 2013 23:23:46 +0200 Thread-Topic: New version of draft-rajtar-dhc-v4configuration-02 posted Thread-Index: Ac5AaNa+XkfVs7YHSJSEFjeFQGjxFQ== Message-ID: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B7631898DB0232BHE111643EMEA1_" MIME-Version: 1.0 Subject: [dhcwg] New version of draft-rajtar-dhc-v4configuration-02 posted 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, 23 Apr 2013 21:23:51 -0000 --_000_8A1B81989BCFAE44A22B2B86BF2B7631898DB0232BHE111643EMEA1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just in case you missed it, a new version of draft-rajtar-dhc-v4configurati= on (02) was recently posted. As this version incorporates the new DCHPv4 over DHCPv6 model described in = the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes based= on the discussions in Orlando, the authors would like request that the WG = chairs make a call for adoption based. Cheers, Ian --_000_8A1B81989BCFAE44A22B2B86BF2B7631898DB0232BHE111643EMEA1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Just in case you missed it, a new version of draft-rajtar-dhc-v4config= uration (02) was recently posted.
 
As this version incorporates the new DCHPv4 over DHCPv6 model describe= d in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes = based on the discussions in Orlando, the authors would like request that th= e WG chairs make a call for adoption based.
 
Cheers,
Ian
 
 
 
 --_000_8A1B81989BCFAE44A22B2B86BF2B7631898DB0232BHE111643EMEA1_-- From internet-drafts@ietf.org Tue Apr 23 21:49:22 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8E21F91B2; Tue, 23 Apr 2013 21:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjjdEdgPdG15; Tue, 23 Apr 2013 21:49:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7624321F8644; Tue, 23 Apr 2013 21:49:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424044921.5146.32569.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 21:49:21 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-unknown-msg-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 04:49:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Handling Unknown DHCPv6 Messages Author(s) : Yong Cui Qi Sun Ted Lemon Filename : draft-ietf-dhc-dhcpv6-unknown-msg-00.txt Pages : 6 Date : 2013-04-23 Abstract: Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific about handling messages with unknown types. This document describes the problems and defines how a DHCPv6 function node should behave in this case. This document updates RFC3315. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sunqi.thu@gmail.com Wed Apr 24 00:02:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0160F21F8F4A for ; Wed, 24 Apr 2013 00:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tm4FFX2Jnjv for ; Wed, 24 Apr 2013 00:02:23 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 238D121F8F44 for ; Wed, 24 Apr 2013 00:02:23 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so425052pde.37 for ; Wed, 24 Apr 2013 00:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:mime-version:content-type:subject:date:references :cc:to:message-id:x-mailer; bh=d9utlzE6zAuCCwbUWK+oNUPUaoUC6xKGQZsqsXwvRE8=; b=BvgPNNGMDn3FMMDbcf3sUunfT0FGRWhusK78L8lPQ3SU6Rt2flQA2bi0gkhNps2g4t JsRxC4WglrQ+fkP2ElPW8+ClaQXH0htL+mzqAwwsoIzNMsDRTT0WFFOTsWswmK6SzJDR f5RCCkMxlMIQt42p1S7Ij9shi2NupAwYmn41yjJrZD61VXxloYj7AFcceKp/uVRw/kp9 CccdW4NjFu3qXXRbDkvXduHQLBhDLG7zdBeWCG+VSlgzZqWONA54zL2TlAga7ykF2hvz VVrHClVVWtV3T1X/SzNa53/0bFumGlOPUSAgEqbdCW74AVM1WEibSjPlDAcpPMJnniXZ uJfQ== X-Received: by 10.67.1.39 with SMTP id bd7mr33218360pad.194.1366786942963; Wed, 24 Apr 2013 00:02:22 -0700 (PDT) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPSA id j13sm2380566pat.17.2013.04.24.00.02.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 00:02:21 -0700 (PDT) From: Qi Sun Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--214813679 Date: Wed, 24 Apr 2013 15:02:06 +0800 References: <20130424044921.5146.32569.idtracker@ietfa.amsl.com> To: "dhcwg@ietf.org WG" Message-Id: <90FBA3F0-A1A9-4FFA-81C9-9C22B480CA1F@gmail.com> X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 24 Apr 2013 05:12:52 -0700 Cc: Chairs Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dhcpv6-unknown-msg-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 07:02:24 -0000 --Apple-Mail-5--214813679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, We have uploaded the 00 version of draft-ietf-dhc-dhcpv6-unknown-msg. = The draft is mainly about how a DHCPv6 relay/server/client handles the = unknown DHCPv6 message. This draft updates RFC3315.=20 The major changes since adoption are: 1) Rename the draft draft-ietf-dhc-dhcpv6-unknown-msg-00 2) Indicate the draft intends to update RFC 3315 3) Specify the definition of 'valid message' for a relay agent 4) Add a paragraph about how a relay would work with firewalls existing = in the Security Considerations 5) Add reference to RFC 2119 6) Correct a couple of typos according to Bernie's comments Please give it a review. Comments are always welcome. Best Regards, Qi Sun Begin forwarded message: > From: internet-drafts@ietf.org > Date: 2013=E5=B9=B44=E6=9C=8824=E6=97=A5 = =E4=B8=8B=E5=8D=8812=E6=97=B649=E5=88=8621=E7=A7=92=E6=A0=BC=E6=9E=97=E5=B0= =BC=E6=B2=BB=E6=A0=87=E5=87=86=E6=97=B6=E9=97=B4+0800 > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-unknown-msg-00.txt >=20 >=20 > 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. >=20 > Title : Handling Unknown DHCPv6 Messages > Author(s) : Yong Cui > Qi Sun > Ted Lemon > Filename : draft-ietf-dhc-dhcpv6-unknown-msg-00.txt > Pages : 6 > Date : 2013-04-23 >=20 > Abstract: > Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't = specific > about handling messages with unknown types. This document describes > the problems and defines how a DHCPv6 function node should behave in > this case. This document updates RFC3315. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-5--214813679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = all,

We have uploaded the 00 version = of draft-ietf-dhc-dhcpv6-unknown-msg. The draft is mainly about how = a DHCPv6 relay/server/client handles the unknown DHCPv6 message. This = draft updates RFC3315. 

The major changes = since adoption are:

1) Rename the draft = draft-ietf-dhc-dhcpv6-unknown-msg-00
2) Indicate the draft intends to = update RFC 3315
3) Specify the definition of 'valid message' for a = relay agent
4) Add a paragraph about how a relay would work with = firewalls existing in the Security Considerations
5) Add reference to = RFC 2119
6) Correct a couple of typos according to Bernie's = comments

Please give it a review. Comments are = always welcome.

Best Regards,
Qi = Sun

Begin forwarded message:

Date: 2013=E5=B9=B44=E6=9C=8824=E6=97=A5 = =E4=B8=8B=E5=8D=8812=E6=97=B649=E5=88=8621=E7=A7=92=E6=A0=BC=E6=9E=97=E5=B0= =BC=E6=B2=BB=E6=A0=87=E5=87=86=E6=97=B6=E9=97=B4+0800
To: i-d-announce@ietf.org
=
Subject: [dhcwg] I-D = Action: = draft-ietf-dhc-dhcpv6-unknown-msg-00.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 =           : Handling = Unknown DHCPv6 Messages
Author(s) =       : Yong Cui
=             &n= bsp;           &nbs= p;Qi Sun
=             &n= bsp;           &nbs= p;Ted Lemon
= Filename        : = draft-ietf-dhc-dhcpv6-unknown-msg-00.txt
Pages =           : 6
Date =            : = 2013-04-23

Abstract:
  Dynamic Host Configuration = Protocol version 6 (DHCPv6) isn't specific
  about = handling messages with unknown types.  This document describes
=   the problems and defines how a DHCPv6 function node should = behave in
  this case.  This document updates = RFC3315.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-unknown-msg
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-00
=

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

________________________= _______________________
dhcwg mailing = list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
<= /div>

= --Apple-Mail-5--214813679-- From leaf.yeh.sdo@gmail.com Wed Apr 24 06:53:26 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5B21F918C for ; Wed, 24 Apr 2013 06:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=2.546, 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 Hs9+ePfGahES for ; Wed, 24 Apr 2013 06:53:24 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7860421F9157 for ; Wed, 24 Apr 2013 06:53:24 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id 10so1144555pdi.29 for ; Wed, 24 Apr 2013 06:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=OGyYCHLPb0KUdA0edqyREZ6FPHf5S5O17llG9N/qKkA=; b=BYhlAOfOwzrxEXJPJ08BG++yVcui0+RvhCbmMZIMKI+EHkz5gaYKELCjWnmXmRrnP/ kTKSy8N0N4cOYD+1HjErwktbgb6WV3DvY7HH6JINABc4lyERbfTLAto+e3oAKNkGFwNc KL2g08nOOmOX5FH8kQOg61vr6B2HRkQD7PJ3AD0MGgGsexTXuKg1vM9HqieSsR61EWCn tdr48OOsRoUgHJKmZkYlGfJkyE6ysk9W4667NLiQECNwxQJWeXVkp9nnMHjnYgV5V1u1 GqpDCbl5DqffzBSZA3ZwQMM0xNjce9huXnaWek4TKNm4xb0CSBnTdCnurQrnwZ5EnRWB 0yGA== X-Received: by 10.66.7.202 with SMTP id l10mr19515697paa.176.1366811604230; Wed, 24 Apr 2013 06:53:24 -0700 (PDT) Received: from PC ([111.193.201.6]) by mx.google.com with ESMTPSA id dg5sm3143061pbc.29.2013.04.24.06.53.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Apr 2013 06:53:23 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" , "'dhcwg'" References: <489D13FBFA9B3E41812EA89F188F018E18515058@xmb-rcd-x04.cisco.com> <5176D408.7020304@gmail.com> In-Reply-To: <5176D408.7020304@gmail.com> Date: Wed, 24 Apr 2013 21:53:17 +0800 Message-ID: <5177e3d3.85b3440a.4a84.0d49@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5AUSW9uIDh5f84RNOMnGtJwBlxxwAeFg9g Content-Language: zh-cn Subject: Re: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt 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 Apr 2013 13:53:26 -0000 > There was also a late IPR disclosure that the working group was not aware of it when the last call started. Existence of IPR claims may have affected the response from WG. Remember that IPR must be disclosed as early as possible (preferably in the individual draft phase). That's my fault though I am not Huawei employee now, but the IPR disclosure from Huawei sounds an defensive (& harmless) IPR, right? > It seems reasonable to focus on a better explanation of why this is a real problem and why the use case is practical rather than theoretical one. We called for interests many times in the ML of the DHC-WG (http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html ) and have some discussion in the ML of routing-discussion (http://www.ietf.org/mail-archive/web/routing-discussion/current/maillist.ht ml ) before. The reason why we need OPTION_PREFIX_POOL is explicit for the automatic route aggregation at provider edge (PE) router, because the DHCPv6-PD mechanism will introduce too many route entries at PE router for every customer network behind the customer edge (CE) routers (DHCPv6-PD clients). Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 24, 2013 2:34 AM To: dhcwg Subject: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt This mail summarizes Work Group Last Call on draft-ietf-dhc-dhcpv6-prefix-pool-opt announced on March 24th and concluded on April 8th, 2013. Sorry for the late announcement. The chairs feel that this document has failed WGLC as there was insufficient consensus to move forward. This does not mean end of life for this draft - it remains a valid WG item and people are encouraged to work on it. There was also a late IPR disclosure that the working group was not aware of it when the last call started. Existence of IPR claims may have affected the response from WG. Remember that IPR must be disclosed as early as possible (preferably in the individual draft phase). Having said that, there were some good technical comments received. Authors are advised to address them and continue work on this draft. It seems reasonable to focus on a better explanation of why this is a real problem and why the use case is practical rather than theoretical one. But the most important issue here is a lack of support. Please address the comments made in this WGLC, find people who are interested in this work and are ready to voice their support when the time comes and only then ask for another WGLC. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Wed Apr 24 07:46:30 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942E821F8A0B for ; Wed, 24 Apr 2013 07:46:30 -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 BZ8j9ltJBlw1 for ; Wed, 24 Apr 2013 07:46:29 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 700B421F8BD4 for ; Wed, 24 Apr 2013 07:46:29 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id d41so786120eek.39 for ; Wed, 24 Apr 2013 07:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=f0IOxxsU5p5zMU7aHR5ehy7p/ys5F9+bhIUYtkUsgrs=; b=HEg78FsXuj94f3SduEEnLRJB7GNBRd7FXrE7k7GKpzixy1HZC2Z9lr4jg2+3ALWfwC e31fcY1n2AyQwyv88AuSKnkJeM7C4iduO/GaxL4p/Yj1n2nQCuy6LpOl0PgcLdmr4c8w /LEJsIYSJ5mUms9rZFtUk2ZTMVJo3KwRa9lK9F3Nkn19/1nmSGnPVsb9LNlZ7L/o5NoO ui2KMVD6fbL/sCI6+40JQGP1iaJrlG8SpfRhw2LYVXcstmc/xk6WO1DyoC+mbM5D0j1f tO2wZOTJ4ACyfCLF8YjJvrkg0SSCz7Ra/6U7yEuohCqnn7bKkiBcgXBlnNZefRGPijOi IcyQ== X-Received: by 10.15.26.6 with SMTP id m6mr29741143eeu.4.1366814788525; Wed, 24 Apr 2013 07:46:28 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id d47sm4664408eem.9.2013.04.24.07.46.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 07:46:27 -0700 (PDT) Message-ID: <5177F036.1000607@gmail.com> Date: Wed, 24 Apr 2013 16:46:14 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leaf Yeh References: <489D13FBFA9B3E41812EA89F188F018E18515058@xmb-rcd-x04.cisco.com> <5176D408.7020304@gmail.com> <5177e3d3.85b3440a.4a84.0d49@mx.google.com> In-Reply-To: <5177e3d3.85b3440a.4a84.0d49@mx.google.com> X-TagToolbar-Keys: D20130424164614143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'dhcwg' Subject: Re: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt 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 Apr 2013 14:46:30 -0000 On 24.04.2013 15:53, Leaf Yeh wrote: >> There was also a late IPR disclosure that the working group was not aware > of it when the last call started. Existence of IPR claims may have affected > the response from WG. Remember that IPR must be disclosed as early as > possible (preferably in the individual draft phase). > > That's my fault though I am not Huawei employee now, but the IPR disclosure > from Huawei sounds an defensive (& harmless) IPR, right? The nature of the IPR claim seems indeed benign. Its content is not an issue, its late disclosure is. >> It seems reasonable to focus on a better explanation of why this is a real > problem and why the use case is practical rather than theoretical one. > > We called for interests many times in the ML of the DHC-WG > (http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html ) and have > some discussion in the ML of routing-discussion Work Group Last Call serves 3 purposes. First is to gather any last moment comments. The second is to confirm whether there is still consensus that that working group still supports the work in question. This was expressed before when the WG decided to adopt a draft. The consensus (or lack of thereof) may change over time for various reasons: problem is better understood, no longer relevant, other solutions may appear, IPR claims may be disclosed in the mean time etc. The third reason for WGLC is to confirm that the group thinks it is ready for publication. Consensus and readiness for publication cannot be implied. It must be explicitly expressed at the time of last call. Otherwise we would have to publish everything that was ever adopted, which would be a bad thing. With may chair hat off, I think people are somewhat interested in solving the problem, but don't like the specific solution too much. Look at the comments you got - "it's a problem that we ought to solve", "I am on the fence with the need for this" or "I will count myself as 'abstain'" is a very different statement than expected "I think this is the right solution, the draft is ready and I support it moving forward". We had a discussion about what to do next, but I don't have any specific advice for you, just some ideas you may possibly consider: Perhaps it would be a useful exercise to approach the problem from a fresh perspective. Try to explore new possibilities. For example: don't put prefix-pool in relay-repl at all and do everything with requestor messages. Cleaner and simpler, but would have the problem of reconfiguring data on the relay and would lack faith sharing. What if your relay could accept reconfigure? Perhaps new message types for prefix-pool exchange would be the right way to go? That's just a loose collection of ideas that doesn't form any coherent solution. I'm not saying that any of these is a good idea, just that it may be helpful to look at the alternatives. I'm not saying that these may be better solutions that the one from prefix-pool-opt. Try to spin up an honest, open minded discussion on the mailing list and see what people think the solution should look like. It is possible that people will realize when discussing alternatives that the they are worse and your original solution was the best one. Another issue raised was that prefix-pool is just one of many other parameters needed. This does not solve relay configuration, but just a small part of it. On the other hand, you probably don't want this to evolve into another router configuration protocol. Perhaps this aspect was what people didn't like? Some of us afraid that there is not enough bandwidth in the work group to go through such a let's-start-from-scratch exercise and they may be right. I don't know. Perhaps an honest talk with people who did some work in the PD area before, but did not support prefix-pool-opt will shed some light here. Were they too busy? Is the issue at hand irrelevant in their opinion? Perhaps the have better solution in mind? Tomek From tomasz.mrugalski@gmail.com Wed Apr 24 09:37:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8B21F9401 for ; Wed, 24 Apr 2013 09:37:03 -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 QPahyZSHgtyp for ; Wed, 24 Apr 2013 09:36:57 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4588D21F93F3 for ; Wed, 24 Apr 2013 09:36:53 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id c50so525524eek.14 for ; Wed, 24 Apr 2013 09:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=DbIYFhC/cg6aSlg8MVoOeXUa5uFImuCURDOpI9hNs9o=; b=YBqwh2hRNsAQn8KjzikPMODc8ZrJnGTrMuwPwD7xdUsQ/92S6RdHuwNj9TmHxGpmyA GQw8Qm+W61Awucc5Pk67Y/AL0RBLUVENOhe5ML3erw0IexoheARyoztAQgad5J36WQua rNYc7LTapWCPoiBuIuaS+2hlSsPwfFziAQ5wGLJIvSiwUrShs2xEr2Mlop52xsoHCIwf 2ovtjIY0KFMw1g256Pw96bHhPB8ZQ2Xriu5HLxApI3lAo889niXX5rJ/j/a9Iz8qRriy aHMt9jta2lAUQiFjP+AwUQeyv3RY00LP7y1A2yvfb9UPSaboY/8IUQ4vxoX7H3udMiSt FiCg== X-Received: by 10.14.105.1 with SMTP id j1mr20478720eeg.6.1366821412392; Wed, 24 Apr 2013 09:36:52 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id w51sm5256751eev.13.2013.04.24.09.36.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 09:36:51 -0700 (PDT) Message-ID: <51780A17.8010503@gmail.com> Date: Wed, 24 Apr 2013 18:36:39 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B7631898DB0232B@HE111643.EMEA1.CDS.T-INTERNAL.COM> X-TagToolbar-Keys: D20130424183639221 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Adoption call for draft-rajtar-dhc-v4configuration-02 - respond by May 8th 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 Apr 2013 16:37:04 -0000 Hi all, This draft is an attempt to summarize the alternatives regarding IPv4 hosts configuration in IPv6-only network. If adopted, it will eventually document DHC recommendation for the stated problem. Currently there is no conclusion stated in the text. The plan is to first see if the WG wants to work on this issue. If the answer is yes, then we will try to reach a consensus on what should the recommendation be. That will be done only after this draft is adopted. As requested by the authors, we are announcing adoption call on draft-rajtar-dhc-v4configuration-02. This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favour of the adoption by replying to this mail. If you are not in favour, please also state your objections in your response. This adoption call will conclude after 2013-05-08. This adoption call is about whether we as a working group want to work on this problem and ultimately make a recommendation. It is not about picking specific technology for IPv4 hosts configuration in IPv6 networks at that time. Background info: This issue was extensively discussed during Orlando meeting. Couple useful things came out of it: DHCPv4-over-DHCPv6 draft that documents what looked like a consensus in the meeting room (adopted couple days ago), a new draft that documents relay behaviour when receiving unknown messages (also adopted recently), and draft-rajtar-dhc-v4configuration received an update to reflect the latest developments. This draft went through an adoption call couple months ago, but it then had a conclusion that pointed out toward a solution that was undefined at that time. The (somewhat premature) conclusion was promptly removed, but it was too late to stop a heated discussion. Regards, Bernie & Tomek On 23.04.2013 23:23, ian.farrer@telekom.de wrote: > Just in case you missed it, a new version of > draft-rajtar-dhc-v4configuration (02) was recently posted. > > As this version incorporates the new DCHPv4 over DHCPv6 model described > in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes > based on the discussions in Orlando, the authors would like request that > the WG chairs make a call for adoption based. > > Cheers, > Ian > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From tomasz.mrugalski@gmail.com Thu Apr 25 06:29:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE721F8D71 for ; Thu, 25 Apr 2013 06:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 vYOrCSXIDoV9 for ; Thu, 25 Apr 2013 06:29:39 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id DBA5221F8AF7 for ; Thu, 25 Apr 2013 06:29:38 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h14so1257430eak.35 for ; Thu, 25 Apr 2013 06:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=GinN4hGObVQKTZSNqJ+maIf4PXxPjlazgxkOvp/X4is=; b=DVgMbvsARsWEsshFlUdyLGffs0Pp2shNrJMhsYOwj0M3fWw/Je9sxjDBodHDS+mc4f i2VFZvzRv+4EZlnpqt3MbTvDW+y9jhDRJbrjCx2h/e1X641lU79/Kw3vTzAZmbVourJ0 rbxIHYkjJVmP6qoNt6N54fFeMv+QrcOFNKSU2KMTDiTEh1TU4jnWLUSFuyJ8C0pLqTLU S2RuurYEPm6N+ON/oo0kTqJnB362p+DT2cydOkkEaXZWPpW5GR30NL0ZAu+F4gG5g1u9 DC3MWCwFriFO33QeEz+K/ETg2x7Uk/0UkkFOgQhwxtpERcWhqd2mKq7Dy9mQzJvD/9av cc9g== X-Received: by 10.15.98.66 with SMTP id bi42mr75038080eeb.39.1366896578070; Thu, 25 Apr 2013 06:29:38 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id n48sm10344808eeg.12.2013.04.25.06.29.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 06:29:37 -0700 (PDT) Message-ID: <51792FBC.5040107@gmail.com> Date: Thu, 25 Apr 2013 15:29:32 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> X-TagToolbar-Keys: D20130425152932948 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 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, 25 Apr 2013 13:29:39 -0000 On 09.04.2013 17:06, Bernie Volz (volz) wrote: > Folks, the authors of draft-ietf-dhc-option-guidelines-11, > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's > ready for a WGLC. There's been discussion and comment already, but more > eyes on and a "final" review of this work are required to advance it. > > This document is critical as it provides guidance to others in the IETF > that may not be DHCP "experts" when they need to write a DHCP option > internet-draft. I strongly support this work. Having such a set of guidelines published will make any review much easier. That will be especially handy for drafts that are written outside of DHC WG. I'm surprised that there's somewhat weak response to this last call so far. Please, read this draft (it is easy read) and state you opinion on it. Disclaimer: Although I'm listed as co-author, I merely joined in around a year ago. This document was created and developed by David Hankins, who unfortunately is no longer active in DHC WG. Tomek From rdroms.ietf@gmail.com Thu Apr 25 10:12:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3812021F96C8 for ; Thu, 25 Apr 2013 10:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 PAHxsWU5Ar6T for ; Thu, 25 Apr 2013 10:12:47 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E03821F96C9 for ; Thu, 25 Apr 2013 10:12:47 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id cz11so2218389qeb.1 for ; Thu, 25 Apr 2013 10:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=jMmKieCV4E0kULhH526vrd1nfDu2gwlVb4C5vVvvroI=; b=RAIBRa7603iH8slrKQaVb/n+x0LKHFrrOnlr7AhWgyr5aIndjYHwDQfPs1hY208zDj 98AX5EQmMybbj5kNP7cL9ZocDA/6aQpi6VsdBN6OXvyiJ0W0U8x3ojV/FH4ddyxQOpik vh0m1XCFER6qp1uoNEWcieNwiIXRruu3yX8TMQqn4goyH5Q9GlwwoMpruHej/N+sFPm+ UlrMJqj754xH30AGWRNXGSV880MUk7pSqOQ56cECtULUkmDNlYh3XDQPdJ3lceCzucDr SO6+p8HPJM75nieNUGGqUr4Mk+xVjo2QeokQu5MD4SLnty1Jr5xchCsSJQiyT9roOR9h TqrQ== X-Received: by 10.224.219.69 with SMTP id ht5mr36001174qab.88.1366909967029; Thu, 25 Apr 2013 10:12:47 -0700 (PDT) Received: from [10.131.32.81] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id kf2sm10993604qeb.4.2013.04.25.10.12.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 10:12:46 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_2ACD8EBE-185B-4A62-A8CF-B3F9A7674888" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ralph Droms In-Reply-To: <516AC316.4020005@gmail.com> Date: Thu, 25 Apr 2013 13:12:44 -0400 Message-Id: References: <516AC316.4020005@gmail.com> To: DHC WG X-Mailer: Apple Mail (2.1503) Cc: "Bernie Bernie Volz \(volz\)" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28 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, 25 Apr 2013 17:12:49 -0000 --Apple-Mail=_2ACD8EBE-185B-4A62-A8CF-B3F9A7674888 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2013, at 10:54 AM 4/14/13, Tomek Mrugalski = wrote: > Folks, > The authors of draft-ietf-dhc-container-opt-07 feel it's ready for = WGLC. Well, one of the authors finds himself in the unusual position of = disagreeing with himself about whether the document is ready for WGLC. Rev -05 of this document went through IESG review in 2009. At the time, = there were several Discuss positions posted against the document. I've = attached a list of the Discuss positions from that IESG review. I think the document needs more work to address these Discuss positions = before it is forwarded to the IESG. Some of the issues need WG = discussion: * exactly what is the deployment/operational scenario for this option = and how is its use constrained to that scenario? * how is (or isn't) the case of "nested" DHCP servers handled? * what are the security implications? * how are conflicts between local configuration and contents of this = option handled? - Ralph >=20 > This draft was active around 2010, but then expired. It was revived > (-06) in December 2012 and updated recently (-07). The last version is > more explicit about which options are not allowed in the container = option. >=20 > Please review the draft and indicate whether or not you feel it is = ready > to be published. We have been getting very anemic responses to = working > group last calls recently. Your response matters, so please do = respond. > Silent support is not enough. If not enough people voice their = support, > the document will not advance. Simply saying "I support this work" is > enough. Providing detailed review is better, but not necessary. >=20 > Bernie and I will evaluate consensus after April 28. >=20 > At the time of this writing, there is no IPR reported against this = draft. >=20 > Tomek --Apple-Mail=_2ACD8EBE-185B-4A62-A8CF-B3F9A7674888 Content-Disposition: attachment; filename=draft-ietf-dhc-container-opt-05-DISCUSS.txt Content-Type: text/plain; name="draft-ietf-dhc-container-opt-05-DISCUSS.txt" Content-Transfer-Encoding: quoted-printable Robert Sparks=20 Discuss (2010-04-13)=20 This document appears to target a very specific type of deployment, but = doesn't=20 explicitly restrict the applicability of the option to that deployment = scenario.=20 Given the very limited semantic definition it's very difficult to = anticipate=20 the potential consequences should some other type of deployment attempt = to use=20 the option, or if the option leaks into unintended places.=20 There was some list discussion around multiple interfaces in an RG, but = it=20 focused on DHCP-clients on those interfaces. It's not clear what could = happen=20 that's sane if the RG element had more than one interface where it was = acting=20 as a server.=20 ---- (4/13/2010 Adopting Cullen Jenning's Discuss) ------=20 I would like the geopriv and ecrit folks to get a chance to look at = this. My=20 understanding of their assumptions about DHCP will work is not at all=20 consistent with this and this could have some fairly significant = implications=20 to plans for Emergency 911 type systems.=20 Today, RG are almost always NATs and they are deployed in a nested = fashion. So=20 the DSL modem may have a RG, but very often another "RG" that is perhaps = a=20 wireless AP is plugged into that. This draft needs advice on how it = works with=20 multiple layers of RGs. My current read of it, it does not look like it = would=20 work in the layered case.=20 This draft needs advice on how the RG deals with conflicts. For example, = if=20 normally it would take whatever DNS server was found by the RG client = and=20 advertise that in the RG server. But imagine the container also has the = name of=20 the DNS server. Which one does the RG Server use?=20 I don't understand why the the SP needs to be able send different = information=20 to the equipment behind the RG than it sends to the RG. Can you clarify = the=20 reasoning behind this requirement?=20 In section 3, the third req bullet point. I'm not clear on the = requirement. Are=20 you saying there much be a way for a SP to add new potion that gets sent = to the=20 user equipment without changing the software/config on the RG? This = would make=20 sense to me as a requirement but I'm not sure this draft meets that. = When the=20 RG Server gets an option it does not know about in he container, what = does it=20 do with it?=20 How is expiry of the information in the container handled? If the SP = wants to=20 change some of the information in it, how is that done?=20 These containers are going to get very large - does anything need to be = said=20 about size? With this work with a 10k container?=20 In section 5.5, can you please explicitly list the things the RG Server = needs=20 to discard - as an implementer I would not know what to do.=20 Can the SP send a container even if the RG client does not request it? = This=20 seems inconsistent with other DHCP stuff. Why is it like this?=20 Can the RG server return a container to someone that requests it and = what goes=20 in it?=20 The idea that DHCP authentication would be configure between two nested = RG in=20 grandma's house seems extremely unlikely. I am not aware of any = deployments=20 that use authenticated DHCP between SP and RG. The idea that I can get = pushed a=20 container with the RG client did not even send a request, seems very = disturbing=20 from a security point of view. This is going to contain things like my = location=20 for E911 calls. I realize that what is possible for the security is = going to be=20 pretty limited but I'd like to see it at least mitigate attackers that = were not=20 on the path between RG Client and SP DHCP server.=20 The statement that the RG server MAY discard everything make a device = that=20 passes nothing useful down fully compliant with the spec. This seems a = bit=20 problematic for trying to deploy services that actually use this. I = rather see=20 something along lines of SHOULD pass it all unless explicitly configured = to=20 block something and default configuration needs to not block.=20 ***************=20 Ronald Bonica=20 Discuss (2009-04-22)=20 This document probably deserves some discussion. To be honest, I am torn=20= between voting YES and DISCUSS. Let's see how the discussion on the call = goes.=20 On the one hand, the DHCP container object is a good thing. It permits = the host=20 and the SP DHCP Server, even when the intervening RG client has no idea = what=20 those two parties are discussing.=20 On the other hand, this conversation could be dangerous. If one were to = think=20 of the customer and SP domains as being separate, the RG client would be = a=20 reasonable place to put the security boundary. If the boundary were = implemented=20 at the RG client, it would be a bad thing for the client to pass on = messages=20 that it doesn't understand.=20 If this option were to be used, each client host would have to protect = itself=20 from bad behavior on the part part of the SP (e.g., installing as route = to=20 0.0.0.0/0 through your other provider, installing a static route to the = SP's=20 competitor through /dev/null).=20 ***************=20 Russ Housley=20 Discuss (2009-04-21)=20 The Gen-ART Review by Scott Brim posted on 7 April 2009 raises some=20 concerns that have not been addressed. Responses to these concerns=20 are needed, even if there are not any document changes. The review=20 can be found at:=20 http://www.softarmor.com/rai/temp-gen-art/=20 draft-ietf-dhc-container-opt-05-brim.txt=20 ***************=20 [Cullen Jennings]=20 Discuss (2009-04-22)=20 My apologies for getting to this draft so late. I did not realize what = it was=20 and did not even realize this work was in progress. It has lots of = implication=20 to VoIP and IpTV work in RAI. These are discus discuss and many of them = simply=20 reflect I am just getting up to speed on this now.=20 I would like the geopriv and ecrit folks to get a chance to look at = this. My=20 understanding of their assumptions about DHCP will work is not at all=20 consistent with this and this could have some fairly significant = implications=20 to plans for Emergency 911 type systems.=20 Today, RG are almost always NATs and they are deployed in a nested = fashion. So=20 the DSL modem may have a RG, but very often another "RG" that is perhaps = a=20 wireless AP is plugged into that. This draft needs advice on how it = works with=20 multiple layers of RGs. My current read of it, it does not look like it = would=20 work in the layered case.=20 This draft needs advice on how the RG deals with conflicts. For example, = if=20 normally it would take whatever DNS server was found by the RG client = and=20 advertise that in the RG server. But imagine the container also has the = name of=20 the DNS server. Which one does the RG Server use?=20 I don't understand why the the SP needs to be able send different = information=20 to the equipment behind the RG than it sends to the RG. Can you clarify = the=20 reasoning behind this requirement?=20 In section 3, the third req bullet point. I'm not clear on the = requirement. Are=20 you saying there much be a way for a SP to add new potion that gets sent = to the=20 user equipment without changing the software/config on the RG? This = would make=20 sense to me as a requirement but I'm not sure this draft meets that. = When the=20 RG Server gets an option it does not know about in he container, what = does it=20 do with it?=20 How is expiry of the information in the container handled? If the SP = wants to=20 change some of the information in it, how is that done?=20 These containers are going to get very large - does anything need to be = said=20 about size? With this work with a 10k container?=20 In section 5.5, can you please explicitly list the things the RG Server = needs=20 to discard - as an implementer I would not know what to do.=20 Can the SP send a container even if the RG client does not request it? = This=20 seems inconsistent with other DHCP stuff. Why is it like this?=20 Can the RG server return a container to someone that requests it and = what goes=20 in it?=20 The idea that DHCP authentication would be configure between two nested = RG in=20 grandma's house seems extremely unlikely. I am not aware of any = deployments=20 that use authenticated DHCP between SP and RG. The idea that I can get = pushed a=20 container with the RG client did not even send a request, seems very = disturbing=20 from a security point of view. This is going to contain things like my = location=20 for E911 calls. I realize that what is possible for the security is = going to be=20 pretty limited but I'd like to see it at least mitigate attackers that = were not=20 on the path between RG Client and SP DHCP server.=20 The statement that the RG server MAY discard everything make a device = that=20 passes nothing useful down fully compliant with the spec. This seems a = bit=20 problematic for trying to deploy services that actually use this. I = rather see=20 something along lines of SHOULD pass it all unless explicitly configured = to=20 block something and default configuration needs to not block.=20 ***************=20 [Dan Romascanu]=20 Discuss (2009-04-21)=20 I share the concerns expressed by othe ADs about the danger of this = document=20 being interpreted as defining an extension of DHCP that would allow = usage as a=20 more generic service configuration protocol. I believe that there is = need for=20 more strict language that clarifies the scope of the container option = and=20 restricts the deployment space to RGs.=20 Specifically wherever it makes sense replace 'configuration information' = by=20 'DHCP configuration information'.=20 Also in the Intorduction section:=20 The DHCP Container option defined in this document provides a=20 mechanism through which the RG DHCP client can pass DHCP options to=20 the RG DHCP server without explicit knowledge of the semantics of=20 those options. With this option, the SP DHCP server can pass both=20 current and future DHCP options to the RG DHCP server.=20 The DHCP Container option does not carry IP addresses, IPv6 prefixes=20= or other information about leases. It carries other configuration=20 information.=20 The last phrase should make clear that the DHCP container option carries=20= configuration information expressed as DHCP options.=20 Also, in the OPS-DIR review by Tina Tsou the observation was made that = it is=20 not clear from the text that the RG client and RG server are always = considered=20 as being physically colocated in the same device. It would be good to = make this=20 statement explicit, to avoid any other 'creative' deployments or=20 interpretations in the future.=20 ***************=20 [Lars Eggert]=20 Comment (2009-04-20)=20 I'm abstaining. Basically, the addition of this option turns DHCP from a = host=20 configuration protocol into a DHCP server operations&management = protocol.=20 That's a pretty dramatic change in scope for DHCP, and even if I thought = this=20 was a good idea, I'm missing documents that describe how a DHCP that had = been=20 extended with this options would be used for this purpose.=20 ***************=20 [Magnus Westerlund]=20 Comment (2009-04-23)=20 I do support the discusses from Cullen on the need to clarify and = explain=20 multi-level deployments.=20 I am also worried about the architectural change and lack of documented=20= analysis on what the change means.=20 ***************=20 [Tim Polk]=20 Discuss (2009-04-22)=20 Joe Salowey's secdir review (posted on 14 April 2009) proposed = clarifying text=20 for the security considerations and raised questions regarding the = suitability=20 of this protocol for interactions between the RG server and client = hosts. I=20 have not seen a response to this message, and am interested in hearing = the=20 author's position on the proposed text and the applicability question. --Apple-Mail=_2ACD8EBE-185B-4A62-A8CF-B3F9A7674888 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_2ACD8EBE-185B-4A62-A8CF-B3F9A7674888-- From jiangsheng@huawei.com Thu Apr 25 18:32:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892F921F9750 for ; Thu, 25 Apr 2013 18:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhBnME2YUi10 for ; Thu, 25 Apr 2013 18:32:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35121F974B for ; Thu, 25 Apr 2013 18:32:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQU73512; Fri, 26 Apr 2013 01:32:14 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 26 Apr 2013 02:31:31 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 26 Apr 2013 02:32:05 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.76]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 26 Apr 2013 09:32:03 +0800 From: Sheng Jiang To: Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHOQbj3vFWTyi2Kp0iqs6H7lkcUYJjns/mg Date: Fri, 26 Apr 2013 01:32:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA1D675@nkgeml512-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> <51792FBC.5040107@gmail.com> In-Reply-To: <51792FBC.5040107@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 01:32:17 -0000 QXMgb25lIG9mIHRoZSBsYXRlLWpvaW4gY29hdXRob3IsIEkgcGVyc29uYWxseSBmaW5kIHN1Y2gg ZG9jdW1lbnQgaXMgdmVyeSB1c2VmdWwgZm9yIGFueSByZWFkZXJzIHdobyBtYXkgY3JlYXRlIG5l dyBESEMgb3B0aW9ucy4gVGhhdCdzIHdoeSBJIHZvbHVudGVlcmVkIHRvIHdha2UgdGhpcyBkcmFm dCB1cCBhbmQgY29tcGxldGUgaXQuIFRoZSBjdXJyZW50IHZlcnNpb24gaGFzIGRvbmUgYSBsb3Qg bW9yZSB3b3JrIGJhc2VkIG9uIHRoZSBwcmV2aW91cyB2ZXJzaW9uLiBJdCBpcyByZWFsIGVhc3kt cmVhZCBhbmQgZ29vZCBndWlkZWxpbmVzIGZvciByZWFkZXJzLiBJIHN1cHBvcnQgdG8gbW92ZSBp dCBmb3J3YXJkLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBUb21layBNcnVnYWxza2kNCj5TZW50OiBU aHVyc2RheSwgQXByaWwgMjUsIDIwMTMgOTozMCBQTQ0KPlRvOiBkaGN3Z0BpZXRmLm9yZw0KPlN1 YmplY3Q6IFJlOiBbZGhjd2ddIFdHTEMgLSBkcmFmdC1pZXRmLWRoYy1vcHRpb24tZ3VpZGVsaW5l cy0xMSAtIFJlc3BvbmQgYnkNCj5BcHJpbCAyNA0KPg0KPk9uIDA5LjA0LjIwMTMgMTc6MDYsIEJl cm5pZSBWb2x6ICh2b2x6KSB3cm90ZToNCj4+IEZvbGtzLCB0aGUgYXV0aG9ycyBvZiBkcmFmdC1p ZXRmLWRoYy1vcHRpb24tZ3VpZGVsaW5lcy0xMSwNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZGhjLW9wdGlvbi1ndWlkZWxpbmVzLTExLCBmZWVsIGl0J3MNCj4+IHJl YWR5IGZvciBhIFdHTEMuICBUaGVyZSdzIGJlZW4gZGlzY3Vzc2lvbiBhbmQgY29tbWVudCBhbHJl YWR5LCBidXQNCj5tb3JlDQo+PiBleWVzIG9uIGFuZCBhICJmaW5hbCIgcmV2aWV3IG9mIHRoaXMg d29yayBhcmUgcmVxdWlyZWQgdG8gYWR2YW5jZSBpdC4NCj4+DQo+PiBUaGlzIGRvY3VtZW50IGlz IGNyaXRpY2FsIGFzIGl0IHByb3ZpZGVzIGd1aWRhbmNlIHRvIG90aGVycyBpbiB0aGUgSUVURg0K Pj4gdGhhdCBtYXkgbm90IGJlIERIQ1AgImV4cGVydHMiIHdoZW4gdGhleSBuZWVkIHRvIHdyaXRl IGEgREhDUCBvcHRpb24NCj4+IGludGVybmV0LWRyYWZ0Lg0KPkkgc3Ryb25nbHkgc3VwcG9ydCB0 aGlzIHdvcmsuIEhhdmluZyBzdWNoIGEgc2V0IG9mIGd1aWRlbGluZXMgcHVibGlzaGVkDQo+d2ls bCBtYWtlIGFueSByZXZpZXcgbXVjaCBlYXNpZXIuIFRoYXQgd2lsbCBiZSBlc3BlY2lhbGx5IGhh bmR5IGZvcg0KPmRyYWZ0cyB0aGF0IGFyZSB3cml0dGVuIG91dHNpZGUgb2YgREhDIFdHLg0KPg0K PkknbSBzdXJwcmlzZWQgdGhhdCB0aGVyZSdzIHNvbWV3aGF0IHdlYWsgcmVzcG9uc2UgdG8gdGhp cyBsYXN0IGNhbGwgc28NCj5mYXIuIFBsZWFzZSwgcmVhZCB0aGlzIGRyYWZ0IChpdCBpcyBlYXN5 IHJlYWQpIGFuZCBzdGF0ZSB5b3Ugb3BpbmlvbiBvbiBpdC4NCj4NCj5EaXNjbGFpbWVyOiBBbHRo b3VnaCBJJ20gbGlzdGVkIGFzIGNvLWF1dGhvciwgSSBtZXJlbHkgam9pbmVkIGluIGFyb3VuZA0K PmEgeWVhciBhZ28uIFRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQgYW5kIGRldmVsb3BlZCBieSBE YXZpZCBIYW5raW5zLA0KPndobyB1bmZvcnR1bmF0ZWx5IGlzIG5vIGxvbmdlciBhY3RpdmUgaW4g REhDIFdHLg0KPg0KPlRvbWVrDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj5kaGN3Z0BpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From shwethab@cisco.com Thu Apr 25 19:00:12 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4142B21F9765 for ; Thu, 25 Apr 2013 19:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHrJRf9nZZV3 for ; Thu, 25 Apr 2013 19:00:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 300C321F9766 for ; Thu, 25 Apr 2013 19:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2260; q=dns/txt; s=iport; t=1366941611; x=1368151211; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=BX8ow9qByN3fRBbZ0mMTsJcT4Bbr56vJtgjVHWh/f+0=; b=HtG7AgjWqvhQWkimdlc3fkRm+4+DFroOKVLPOSCB7TxEChmtZbTfq0nn ndgOIt3UwGukqVf1IKAxjg1GiBduU0hSYCq7w0SEJs5Dd5MSUYvGYC9K+ CQn7eRd/deGyy4NaM8/vVi40Dlck4HU49M+sVsDguaTtbY0SUiHHpT4wS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAL7eeVGtJXG9/2dsb2JhbABRgwY2vjCBBxZ0gh8BAQEEAQEBNzEDFwYBCBEEAQEBChQJLgsUCQgCBAESCIgMDL5ojwQ4BoJnYQOYQY99gw6CKA X-IronPort-AV: E=Sophos;i="4.87,554,1363132800"; d="scan'208";a="203232721" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 26 Apr 2013 02:00:10 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3Q20AlQ029780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 02:00:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 21:00:10 -0500 From: "Shwetha Bhandari (shwethab)" To: Sheng Jiang , Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHOQbjyBibr5TKyi0aEtz2soJaHCpjoDBMAgABkVIA= Date: Fri, 26 Apr 2013 02:00:10 +0000 Message-ID: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AA1D675@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.65.60.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 02:00:12 -0000 I have read and strongly support this work too. I find it very useful especially when designing new DHCP options. Shwetha=20 On 4/26/13 7:02 AM, "Sheng Jiang" wrote: >As one of the late-join coauthor, I personally find such document is very >useful for any readers who may create new DHC options. That's why I >volunteered to wake this draft up and complete it. The current version >has done a lot more work based on the previous version. It is real >easy-read and good guidelines for readers. I support to move it forward. > >Best regards, > >Sheng > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>Of Tomek Mrugalski >>Sent: Thursday, April 25, 2013 9:30 PM >>To: dhcwg@ietf.org >>Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - >>Respond by >>April 24 >> >>On 09.04.2013 17:06, Bernie Volz (volz) wrote: >>> Folks, the authors of draft-ietf-dhc-option-guidelines-11, >>> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel >>>it's >>> ready for a WGLC. There's been discussion and comment already, but >>more >>> eyes on and a "final" review of this work are required to advance it. >>> >>> This document is critical as it provides guidance to others in the IETF >>> that may not be DHCP "experts" when they need to write a DHCP option >>> internet-draft. >>I strongly support this work. Having such a set of guidelines published >>will make any review much easier. That will be especially handy for >>drafts that are written outside of DHC WG. >> >>I'm surprised that there's somewhat weak response to this last call so >>far. Please, read this draft (it is easy read) and state you opinion on >>it. >> >>Disclaimer: Although I'm listed as co-author, I merely joined in around >>a year ago. This document was created and developed by David Hankins, >>who unfortunately is no longer active in DHC WG. >> >>Tomek >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From phdgang@gmail.com Thu Apr 25 19:32:08 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EB621F977F for ; Thu, 25 Apr 2013 19:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeITJtYJFGJs for ; Thu, 25 Apr 2013 19:32:07 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAC921F977B for ; Thu, 25 Apr 2013 19:32:07 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id g10so50590qah.11 for ; Thu, 25 Apr 2013 19:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oPzdRM4pow90n/0ilVExg6y4P5QClxmGJ5uGXocm37k=; b=izyNglTzaiUmgJE986VkycHIySPFnXADVJ+uf2HSNybL0xO0mOkNtbRr1ASfJYcTf2 QhEbOxkInTUKQi20xC8XHtnadhnKJx2jvBuj+GyynoXqhXlGPQgPsB+HTF7juzNHXk5l yN/7dj1oXvC3Oy79/JrfQ0arJO4X07AeD3p1xBHdCLuVkAmUdhJDmSGaUcoR/8C6+54C CsmQi7qEGfbDEXzabdpe4B0t3+q+WtDxhxHvZSvPjbvsMMu1rMOxOa6fVlk/d0MTdjyN HI9nY2h9oCRbMG93RgilTZqQRFukM2QxTMNf36NpawsmFrcA9ZUW1LJEUT3tQ/F5rQae nFVA== MIME-Version: 1.0 X-Received: by 10.224.181.200 with SMTP id bz8mr38624810qab.68.1366943526894; Thu, 25 Apr 2013 19:32:06 -0700 (PDT) Received: by 10.49.5.129 with HTTP; Thu, 25 Apr 2013 19:32:06 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AA1D675@nkgeml512-mbx.china.huawei.com> Date: Fri, 26 Apr 2013 10:32:06 +0800 Message-ID: From: GangChen To: "dhcwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 02:32:08 -0000 I support this WGLC. The draft already has stable and useful contents. BRs Gang 2013/4/26, Shwetha Bhandari (shwethab) : > I have read and strongly support this work too. I find it very useful > especially when designing new DHCP options. > > Shwetha > > On 4/26/13 7:02 AM, "Sheng Jiang" wrote: > >>As one of the late-join coauthor, I personally find such document is very >>useful for any readers who may create new DHC options. That's why I >>volunteered to wake this draft up and complete it. The current version >>has done a lot more work based on the previous version. It is real >>easy-read and good guidelines for readers. I support to move it forward. >> >>Best regards, >> >>Sheng >> >>>-----Original Message----- >>>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>>Of Tomek Mrugalski >>>Sent: Thursday, April 25, 2013 9:30 PM >>>To: dhcwg@ietf.org >>>Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - >>>Respond by >>>April 24 >>> >>>On 09.04.2013 17:06, Bernie Volz (volz) wrote: >>>> Folks, the authors of draft-ietf-dhc-option-guidelines-11, >>>> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel >>>>it's >>>> ready for a WGLC. There's been discussion and comment already, but >>>more >>>> eyes on and a "final" review of this work are required to advance it. >>>> >>>> This document is critical as it provides guidance to others in the IETF >>>> that may not be DHCP "experts" when they need to write a DHCP option >>>> internet-draft. >>>I strongly support this work. Having such a set of guidelines published >>>will make any review much easier. That will be especially handy for >>>drafts that are written outside of DHC WG. >>> >>>I'm surprised that there's somewhat weak response to this last call so >>>far. Please, read this draft (it is easy read) and state you opinion on >>>it. >>> >>>Disclaimer: Although I'm listed as co-author, I merely joined in around >>>a year ago. This document was created and developed by David Hankins, >>>who unfortunately is no longer active in DHC WG. >>> >>>Tomek >>> >>>_______________________________________________ >>>dhcwg mailing list >>>dhcwg@ietf.org >>>https://www.ietf.org/mailman/listinfo/dhcwg >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From internet-drafts@ietf.org Thu Apr 25 20:56:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FB321E8048; Thu, 25 Apr 2013 20:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.232, 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 5Qkpp1wOqBBl; Thu, 25 Apr 2013 20:56:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2E21F8EEA; Thu, 25 Apr 2013 20:56:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426035621.11673.30094.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 20:56:21 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-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, 26 Apr 2013 03:56:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Prefix Pool Option for DHCPv6 Relay Agent on the Provide= r Edge Routers Author(s) : Leaf Y. Yeh Ted Lemon Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-prefix-pool-opt-03.txt Pages : 13 Date : 2013-04-25 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 active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-pool-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-prefix-pool-opt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.yeh.sdo@gmail.com Thu Apr 25 22:36:41 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183FE21F97E1 for ; Thu, 25 Apr 2013 22:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AA9XD-EzcENE for ; Thu, 25 Apr 2013 22:36:40 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 853AD21F97DC for ; Thu, 25 Apr 2013 22:36:40 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id rr4so1022973pbb.24 for ; Thu, 25 Apr 2013 22:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=JJTTXV0mkR3xkxhnaga7WsiIRojeXo1tBT3/buk8Co0=; b=L4E0WWUkK/xqVuS9hDXkoMMvmLhaWoV0mhlIVW4YAOZO1avc3jXs7cOFhyY2x10eD+ 6A92S5lXn02ACeKFNV4BEZbwxwbnKXNcbK2AA6zptqjAEpDf0L4i37uIBtFyTf+F7BAp vKZXFR0dS48/XI9LgSw2CKZpA8E7Xz2KlONIjrxstRjYrDmloav0Gn1S4yzl77DWIm5J YgLdvu2nkVFFqiRkCy7Y208aS6N71Tihaqofbv90vCmwEF5c96hcSKVyZ7WK/kum13LK 0yCfIYImtwwph6DRRqnIF8501ZOtmGdHNViBspCcfRIWzW8p3Ldlbnemui+7BYx9Jeb2 Z3bA== X-Received: by 10.66.190.2 with SMTP id gm2mr29167738pac.25.1366954600310; Thu, 25 Apr 2013 22:36:40 -0700 (PDT) Received: from PC ([111.193.201.6]) by mx.google.com with ESMTPSA id br2sm10165073pbc.46.2013.04.25.22.36.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Apr 2013 22:36:39 -0700 (PDT) From: "Leaf Yeh" To: "'Tomek Mrugalski'" References: <489D13FBFA9B3E41812EA89F188F018E18515058@xmb-rcd-x04.cisco.com> <5176D408.7020304@gmail.com> In-Reply-To: <5176D408.7020304@gmail.com> Date: Fri, 26 Apr 2013 13:36:33 +0800 Message-ID: <517a1267.62ae440a.3f5e.1e53@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5AUSW9uIDh5f84RNOMnGtJwBlxxwB6j3OQ Content-Language: zh-cn Cc: 'dhcwg' Subject: Re: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 05:36:41 -0000 Tomek - Authors are advised to address them and continue work on this draft. FYI, I've updated the draft (OPTION_PREFIX_POOL) to be ver.-03 (http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 ). Hope it could have solved all the technical comments in the last WGLC. Definitely we need more discussion on it, especially for the topic below: Tomek - It seems reasonable to focus on a better explanation of why this is a real problem and why the use case is practical rather than theoretical one. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 24, 2013 2:34 AM To: dhcwg Subject: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt This mail summarizes Work Group Last Call on draft-ietf-dhc-dhcpv6-prefix-pool-opt announced on March 24th and concluded on April 8th, 2013. Sorry for the late announcement. The chairs feel that this document has failed WGLC as there was insufficient consensus to move forward. This does not mean end of life for this draft - it remains a valid WG item and people are encouraged to work on it. There was also a late IPR disclosure that the working group was not aware of it when the last call started. Existence of IPR claims may have affected the response from WG. Remember that IPR must be disclosed as early as possible (preferably in the individual draft phase). Having said that, there were some good technical comments received. Authors are advised to address them and continue work on this draft. It seems reasonable to focus on a better explanation of why this is a real problem and why the use case is practical rather than theoretical one. But the most important issue here is a lack of support. Please address the comments made in this WGLC, find people who are interested in this work and are ready to voice their support when the time comes and only then ask for another WGLC. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From msiodelski@gmail.com Fri Apr 26 01:21:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788AA21F97F8 for ; Fri, 26 Apr 2013 01:21:34 -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 ZUxKfXPWE8Sn for ; Fri, 26 Apr 2013 01:21:31 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8889E21F97D1 for ; Fri, 26 Apr 2013 01:21:23 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id l10so1563368eei.4 for ; Fri, 26 Apr 2013 01:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=D6zqQ7olTpUr2Fyh2vY4RjYL4PXdOqZTMVisKhN/eXs=; b=PLOVL7IjFnGf0h7bgrCehrgKCYBVOZUqN6qEHmQFZV0ce8tf37aBawoXl8x7Qud6XF AsrD4muAtnWlQEPTe8VGuKHv4BWtmu/474FL5KGruALAMB9+vV5ZFeDooaZu8XtANaoO RuvumQrKb3sdKubEQNgHyjVdZ0SG3cM63XCsV92hptOUfU0fKZHw4reVmpoZSrD+r8dV KkpKOqsNhyOasKCanupS34pCKCXUXVGk078zbGJjVZI8hFxsonT3SYxy+o9Xc81miiYe /3pmK7gbkL48NBB+InWPb1y3jT3E6ftnzRokLqZBpxN6C00Z+4udt/rnfFIhEZVtFcvL iGMw== X-Received: by 10.14.5.72 with SMTP id 48mr84730789eek.19.1366964483167; Fri, 26 Apr 2013 01:21:23 -0700 (PDT) Received: from [192.168.0.193] (89-75-115-194.dynamic.chello.pl. [89.75.115.194]) by mx.google.com with ESMTPSA id m48sm7658051eeu.15.2013.04.26.01.21.21 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 26 Apr 2013 01:21:22 -0700 (PDT) Message-ID: <1366964480.3011.2.camel@marcin-lenovo> From: Marcin Siodelski To: GangChen Date: Fri, 26 Apr 2013 10:21:20 +0200 In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AA1D675@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.6.4 (3.6.4-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 08:21:48 -0000 X-List-Received-Date: Fri, 26 Apr 2013 08:21:48 -0000 I am one of the late joint co-authors of this draft. I also find this very important to have such a guideline document. I strongly support advancing this document. Marcin On Fri, 2013-04-26 at 10:32 +0800, GangChen wrote: > I support this WGLC. The draft already has stable and useful contents. > > BRs > > Gang > 2013/4/26, Shwetha Bhandari (shwethab) : > > I have read and strongly support this work too. I find it very useful > > especially when designing new DHCP options. > > > > Shwetha > > > > On 4/26/13 7:02 AM, "Sheng Jiang" wrote: > > > >>As one of the late-join coauthor, I personally find such document is very > >>useful for any readers who may create new DHC options. That's why I > >>volunteered to wake this draft up and complete it. The current version > >>has done a lot more work based on the previous version. It is real > >>easy-read and good guidelines for readers. I support to move it forward. > >> > >>Best regards, > >> > >>Sheng > >> > >>>-----Original Message----- > >>>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > >>>Of Tomek Mrugalski > >>>Sent: Thursday, April 25, 2013 9:30 PM > >>>To: dhcwg@ietf.org > >>>Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - > >>>Respond by > >>>April 24 > >>> > >>>On 09.04.2013 17:06, Bernie Volz (volz) wrote: > >>>> Folks, the authors of draft-ietf-dhc-option-guidelines-11, > >>>> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel > >>>>it's > >>>> ready for a WGLC. There's been discussion and comment already, but > >>>more > >>>> eyes on and a "final" review of this work are required to advance it. > >>>> > >>>> This document is critical as it provides guidance to others in the IETF > >>>> that may not be DHCP "experts" when they need to write a DHCP option > >>>> internet-draft. > >>>I strongly support this work. Having such a set of guidelines published > >>>will make any review much easier. That will be especially handy for > >>>drafts that are written outside of DHC WG. > >>> > >>>I'm surprised that there's somewhat weak response to this last call so > >>>far. Please, read this draft (it is easy read) and state you opinion on > >>>it. > >>> > >>>Disclaimer: Although I'm listed as co-author, I merely joined in around > >>>a year ago. This document was created and developed by David Hankins, > >>>who unfortunately is no longer active in DHC WG. > >>> > >>>Tomek > >>> > >>>_______________________________________________ > >>>dhcwg mailing list > >>>dhcwg@ietf.org > >>>https://www.ietf.org/mailman/listinfo/dhcwg > >>_______________________________________________ > >>dhcwg mailing list > >>dhcwg@ietf.org > >>https://www.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From kkinnear@cisco.com Fri Apr 26 06:58:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1D21F9921 for ; Fri, 26 Apr 2013 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnZ067iFFR2a for ; Fri, 26 Apr 2013 06:58:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E4F9E21F84AD for ; Fri, 26 Apr 2013 06:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3657; q=dns/txt; s=iport; t=1366984737; x=1368194337; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1EcuCwWKsLeBtxjbbUAgTlEIlQQ2LnMFvb1ThXdCUMk=; b=gi7+YNU9h1f9JSF7Dh9vlMI+ThGc7NoMaQXmskyum2XgWyV++sTM+cGo Rj2RXIP110n/2qg3ZnzmFKMlmLbBBGbhGUpQhdqrNzet2y4NF2C+Dp4Dn a0Y38PSYQR7tqOno8fEjFJzFIT6Zg3ZXwGJkxW3bphYYIVLMkwrb4zBVD M=; X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="200475768" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 26 Apr 2013 13:58:56 +0000 Received: from che-vpn-cluster-2-32.cisco.com (che-vpn-cluster-2-32.cisco.com [10.86.242.32]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3QDwtCP005780; Fri, 26 Apr 2013 13:58:56 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <1366964480.3011.2.camel@marcin-lenovo> Date: Fri, 26 Apr 2013 09:58:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AA1D675@nkgeml512-mbx.china.huawei.com> <1366964480.3011.2.camel@marcin-lenovo> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1278) Cc: Kim Kinnear Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 13:58:58 -0000 I am also late, though not a co-author of this draft -- I'm just late. I have read this document and support advancing it beyond last call. Regards -- Kim On Apr 26, 2013, at 4:21 AM, Marcin Siodelski wrote: > I am one of the late joint co-authors of this draft. I also find this > very important to have such a guideline document. I strongly support > advancing this document. >=20 > Marcin >=20 > On Fri, 2013-04-26 at 10:32 +0800, GangChen wrote: >> I support this WGLC. The draft already has stable and useful = contents. >>=20 >> BRs >>=20 >> Gang >> 2013/4/26, Shwetha Bhandari (shwethab) : >>> I have read and strongly support this work too. I find it very = useful >>> especially when designing new DHCP options. >>>=20 >>> Shwetha >>>=20 >>> On 4/26/13 7:02 AM, "Sheng Jiang" wrote: >>>=20 >>>> As one of the late-join coauthor, I personally find such document = is very >>>> useful for any readers who may create new DHC options. That's why I >>>> volunteered to wake this draft up and complete it. The current = version >>>> has done a lot more work based on the previous version. It is real >>>> easy-read and good guidelines for readers. I support to move it = forward. >>>>=20 >>>> Best regards, >>>>=20 >>>> Sheng >>>>=20 >>>>> -----Original Message----- >>>>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On = Behalf >>>>> Of Tomek Mrugalski >>>>> Sent: Thursday, April 25, 2013 9:30 PM >>>>> To: dhcwg@ietf.org >>>>> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - >>>>> Respond by >>>>> April 24 >>>>>=20 >>>>> On 09.04.2013 17:06, Bernie Volz (volz) wrote: >>>>>> Folks, the authors of draft-ietf-dhc-option-guidelines-11, >>>>>> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, = feel >>>>>> it's >>>>>> ready for a WGLC. There's been discussion and comment already, = but >>>>> more >>>>>> eyes on and a "final" review of this work are required to advance = it. >>>>>>=20 >>>>>> This document is critical as it provides guidance to others in = the IETF >>>>>> that may not be DHCP "experts" when they need to write a DHCP = option >>>>>> internet-draft. >>>>> I strongly support this work. Having such a set of guidelines = published >>>>> will make any review much easier. That will be especially handy = for >>>>> drafts that are written outside of DHC WG. >>>>>=20 >>>>> I'm surprised that there's somewhat weak response to this last = call so >>>>> far. Please, read this draft (it is easy read) and state you = opinion on >>>>> it. >>>>>=20 >>>>> Disclaimer: Although I'm listed as co-author, I merely joined in = around >>>>> a year ago. This document was created and developed by David = Hankins, >>>>> who unfortunately is no longer active in DHC WG. >>>>>=20 >>>>> Tomek >>>>>=20 >>>>> _______________________________________________ >>>>> dhcwg mailing list >>>>> dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Fri Apr 26 07:59:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2D21F9897; Fri, 26 Apr 2013 07:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 AagpJxiy8EaW; Fri, 26 Apr 2013 07:59:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36421F9876; Fri, 26 Apr 2013 07:59:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426145911.30060.7642.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 07:59:11 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 14:59:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv4 over DHCPv6 Transport Author(s) : Qi Sun Yong Cui Marcin Siodelski Suresh Krishnan Ian Farrer Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6-00.txt Pages : 9 Date : 2013-04-26 Abstract: This document describes a mechanism for obtaining IPv4 address and other parameters in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From msiodelski@gmail.com Fri Apr 26 08:18:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B5E21F99BF for ; Fri, 26 Apr 2013 08:18:12 -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 MBkgTbAngHY5 for ; Fri, 26 Apr 2013 08:18:12 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1502121F998C for ; Fri, 26 Apr 2013 08:18:11 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id o10so1768515eaj.23 for ; Fri, 26 Apr 2013 08:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=43xn0j+zF9yn1hZyIm5vliOXraAfQioy5Ks5Y9q8ydw=; b=mhDr7CKBKjErpRtBdogfNVmX4WG8hgZ826sHwwftilEgzCdyinzKqlOaRnhqlMGWZU IeXzz1wXqJrQKk82ao7J9pCytE3elx58W0SIp3BkFyGIlgFxTzb7OJrW18QOP9S2YZY7 fDkyAVoPfkgEZirXjlcmlzR3hop7pizjw+TGRiTB7viijfMswmRms6x5+J3ZUhJ2mRnn RI0jQjPZNo6LbBbTb2BvGR1/p2+oewXFstpzIy1EdoxbGBIdPpmYAs0GKH/A1CD2tIkh TgmxadCn16C6sVTUuQt4D3YXRXQsIbZ4BgPDLNgZkNoUl9LQxJSfWpKXp/m15EGFIxHj hyvw== X-Received: by 10.15.43.73 with SMTP id w49mr88940193eev.12.1366989491035; Fri, 26 Apr 2013 08:18:11 -0700 (PDT) Received: from [46.77.0.13] (apn-46-77-0-13.dynamic.cdma.plus.pl. [46.77.0.13]) by mx.google.com with ESMTPSA id i53sm16494866eeu.5.2013.04.26.08.18.09 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 26 Apr 2013 08:18:09 -0700 (PDT) Message-ID: <1366989482.20228.10.camel@marcin-lenovo> From: Marcin Siodelski To: dhcwg@ietf.org Date: Fri, 26 Apr 2013 17:18:02 +0200 In-Reply-To: <5170DE2C.4010200@gmail.com> References: <1365009642.19971.22.camel@marcin-lenovo> <515C69A4.7000903@gmail.com> <515D592B.4040609@viagenie.ca> <5170DE2C.4010200@gmail.com> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.6.4 (3.6.4-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:18:13 -0000 On Thu, 2013-04-18 at 23:03 -0700, Tomek Mrugalski wrote: > This adoption call deadline has passed. I'm very happy that we had a > healthy discussion with many useful comments posted. Most comments were > supporting adoption. There were two objections (one was later > withdrawn). This means that the WG has reached a strong consensus to > adopt this work. > > Authors, please upload this work as draft-ietf-dhc-dhcpv4-over-dhcpv6-00 > once you address all received comments. Thanks to everybody who have taken time to review this document and shared comments. We tried to address comments from the adoption call period and the uploaded -00 version includes relevant changes. In particular: 1) Rename the document draft-ietf-dhc-dhcpv4-over-dhcpv6-00 2) Add some text in Introduction section about the motivation and scope 3) Add a paragraph in Section 6 about the use of IPv6 interface 4) Add some text in Section 8 to clarify what a 'DHCPv4 server engine' is, and specify the related discussions are out of scope. 5) Rewrite Section 9 (Security Considerations) 6) Move RFC2119 to the list of Normative References All further comments regarding the latest version of this document are appreciated. Links: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-00 Cheers, Marcin From rjsparks@nostrum.com Fri Apr 26 08:42:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3560B21F9A16; Fri, 26 Apr 2013 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 zmrnO4NroEmx; Fri, 26 Apr 2013 08:42:10 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF521F9A0C; Fri, 26 Apr 2013 08:42:10 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3QFg80u049436 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 26 Apr 2013 10:42:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <517AA051.8080506@nostrum.com> Date: Fri, 26 Apr 2013 10:42:09 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dhcwg@ietf.org, ietf@ietf.org, General Area Review Team , draft-ietf-dhc-triggered-reconfigure@tools.ietf.org Content-Type: multipart/alternative; boundary="------------050301090000090703000601" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:42:11 -0000 This is a multi-part message in MIME format. --------------050301090000090703000601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. Nits/editorial comments: --------------050301090000090703000601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
      the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list).  This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own).

introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured.

Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be supported, but are not discussed in this document.
places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state.

Nits/editorial comments: --------------050301090000090703000601-- From mohamed.boucadair@orange.com Fri Apr 26 09:02:47 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9967721F9A5D; Fri, 26 Apr 2013 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr8Zjd1yoUAg; Fri, 26 Apr 2013 09:02:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C5E9221F9A5B; Fri, 26 Apr 2013 09:02:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8D0832645A1; Fri, 26 Apr 2013 18:02:45 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 69E8535C048; Fri, 26 Apr 2013 18:02:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 26 Apr 2013 18:02:45 +0200 From: To: Robert Sparks , "dhcwg@ietf.org" , "ietf@ietf.org" , General Area Review Team , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Date: Fri, 26 Apr 2013 17:58:38 +0200 Thread-Topic: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 Thread-Index: Ac5ClKF6HmqJ6RojQf+w5CK04H/aHwAAkkJb Message-ID: <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> References: <517AA051.8080506@nostrum.com> In-Reply-To: <517AA051.8080506@nostrum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.25.35414 Subject: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:02:47 -0000 Dear Robert, Thank you for the review. Please see inline. Cheers, Med ________________________________________ De : dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] de la part de Robert S= parks [rjsparks@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 =C0 : dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-d= hc-triggered-reconfigure@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the conten= t of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identif= ier list). This decision is local to the relay (e.g., it may be based on o= bserved events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a rel= ay's first message included client A, then the retransmission included clie= nts A and B, but that retransmission crosses with a success RECONFIGURE-REP= LY to the request that only included client A, the relay will think it succ= eeded in asking A and B to be reconfigured. Med: This example does not apply for that text. In fact, the example should= be the other way around. Perhaps, this can be made clearer if we change "(= e.g., update the Client Identifier list)" to "(e.g., remove a client from t= he Client Identifier list)". Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, bu= t are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). I= s there some other document that defines this requirement that you can refe= rence? Med: I'm not aware of any; but if there is one we can cite it. If not, the requirement should be discussed in this document. Alternativel= y, you could change the sentence to talk about the consequences of not havi= ng a proprietary means for recovering state. Med: Will consider that option if you think this is really needed. Nits/editorial comments: From rjsparks@nostrum.com Fri Apr 26 09:19:31 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1B721F9987; Fri, 26 Apr 2013 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 p94gESGCTazx; Fri, 26 Apr 2013 09:19:30 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CCEAA21F9878; Fri, 26 Apr 2013 09:19:30 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3QGJTZr054170 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 26 Apr 2013 11:19:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <517AA910.8030608@nostrum.com> Date: Fri, 26 Apr 2013 11:19:28 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "dhcwg@ietf.org" , General Area Review Team , "ietf@ietf.org" , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:19:31 -0000 On 4/26/13 10:58 AM, mohamed.boucadair@orange.com wrote: > Dear Robert, > > Thank you for the review. > Please see inline. > > Cheers, > Med > ________________________________________ > De : dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] de la part de Robert Sparks [rjsparks@nostrum.com] > Date d'envoi : vendredi 26 avril 2013 17:42 > À : dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org > Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-dhc-triggered-reconfigure-05 > Reviewer: Robert Sparks > Review Date: April 26, 2013 > IETF LC End Date: May 6, 2013 > IESG Telechat date: May 16, 2013 > > Summary: This draft is on the right track but has open issues, described in > the review. > > Major issues: > > Overall, this document is solid, but I think there is a bug in section 6.3. > I could be wrong, but If I'm right, this paragraph: > > When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). > > introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. > > Med: This example does not apply for that text. Really? What text constrains how you change what's in the retransmission? > In fact, the example should be the other way around. Perhaps, this can be made clearer if we change "(e.g., update the Client Identifier list)" to "(e.g., remove a client from the Client Identifier list)". If I understand you correctly, you need more than just changing a parenthetical e.g.. I think you're saying that you are constraining the message changes to be such that if anything earlier in the retransmission sequence succeeded, the request in the retransmission would also have succeeded. But why do you need that much complexity? Do you have it already with any other request? > > Minor issues: > > This sentence: > > Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. > places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? > > Med: I'm not aware of any; but if there is one we can cite it. > > If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. > > Med: Will consider that option if you think this is really needed. > > Nits/editorial comments: From volz@cisco.com Fri Apr 26 21:23:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC5C21F988D; Fri, 26 Apr 2013 21:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Li2P7zNg8Mf; Fri, 26 Apr 2013 21:23:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0054F21F988A; Fri, 26 Apr 2013 21:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4601; q=dns/txt; s=iport; t=1367036622; x=1368246222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ocoessXB2ZCDisMmRfUCZNp1/RWstXWXI9AVwd/qPao=; b=Dk6BCwR7kSu4yNeLFxo6KN5wdiXeG959fGc3IjK36MSJ7s8uVRphMlbD ZG8izJPgUjRO1zaEBhS8i1JnRQ44R9lPBD2hyNi1nqxzMHzgpGlMBr+tt 8f4XVWbmKmGrug+pWVs6+s56R41ClYcTPCM8Fi8hUeSJ+4QpTZxoSx9SX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAN5Re1GtJV2Z/2dsb2JhbABRgwc2vkOBBBZ0gh8BAQEDAQEBAWsLBQcEAgEIDgMDAQEBAQodBycLFAkIAgQBDQUIiAYGDL8UjmExBwaCZ2EDiFqDRYwjhV+KJYMOgig X-IronPort-AV: E=Sophos;i="4.87,562,1363132800"; d="scan'208";a="203704341" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 27 Apr 2013 04:23:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3R4NeIb030738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Apr 2013 04:23:40 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 23:23:40 -0500 From: "Bernie Volz (volz)" To: Robert Sparks , "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 Thread-Index: AQHOQpnwLrlO/DVOGkmT6MAmTnOo8Zjpd9oA Date: Sat, 27 Apr 2013 04:23:39 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1851CFD5@xmb-rcd-x04.cisco.com> References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> <517AA910.8030608@nostrum.com> In-Reply-To: <517AA910.8030608@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.178] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , General Area Review Team , "ietf@ietf.org" , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 04:23:43 -0000 Robert: The reason to allow this is that otherwise client A will be unnecessarily r= econfigured many times. (It is also possible that a client might Renew on i= ts own just as this is happening and thus it can also be removed from the R= econfigure.) I think the text should be cleaned up to indicate that allowing removal of = already reconfigured clients is recommended (to prevent unnecessary reconfi= gures) when retransmitting the Reconfigure-Request. Note that if clients are added, that is not a retransmission but requires a= "new" message (new XID). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R= obert Sparks Sent: Friday, April 26, 2013 12:19 PM To: mohamed.boucadair@orange.com Cc: dhcwg@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-dhc= -triggered-reconfigure@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfig= ure-05 On 4/26/13 10:58 AM, mohamed.boucadair@orange.com wrote: > Dear Robert, > > Thank you for the review. > Please see inline. > > Cheers, > Med > ________________________________________ > De : dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] de la part de=20 > Robert Sparks [rjsparks@nostrum.com] Date d'envoi : vendredi 26 avril=20 > 2013 17:42 =C0 : dhcwg@ietf.org; ietf@ietf.org; General Area Review=20 > Team; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org > Objet : [dhcwg] Gen-art review:=20 > draft-ietf-dhc-triggered-reconfigure-05 > > I am the assigned Gen-ART reviewer for this draft. For background on=20 > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments=20 > you may receive. > > Document: draft-ietf-dhc-triggered-reconfigure-05 > Reviewer: Robert Sparks > Review Date: April 26, 2013 > IETF LC End Date: May 6, 2013 > IESG Telechat date: May 16, 2013 > > Summary: This draft is on the right track but has open issues, described = in > the review. > > Major issues: > > Overall, this document is solid, but I think there is a bug in section 6.= 3. > I could be wrong, but If I'm right, this paragraph: > > When retransmission is required, the relay may decide to correct the cont= ent of RECONFIGURE-REQUEST message it issues (e.g., update the Client Ident= ifier list). This decision is local to the relay (e.g., it may be based on= observed events such as one or more clients were reconfigured on their own= ). > > introduces a race-condition that could lead to an erroneous state. If a r= elay's first message included client A, then the retransmission included cl= ients A and B, but that retransmission crosses with a success RECONFIGURE-R= EPLY to the request that only included client A, the relay will think it su= cceeded in asking A and B to be reconfigured. > > Med: This example does not apply for that text. Really? What text constrains how you change what's in the retransmission? > In fact, the example should be the other way around. Perhaps, this can = be made clearer if we change "(e.g., update the Client Identifier list)" to= "(e.g., remove a client from the Client Identifier list)". If I understand you correctly, you need more than just changing a parenthet= ical e.g.. I think you're saying that you are constraining the message chan= ges to be such that if anything earlier in the retransmission sequence succ= eeded, the request in the retransmission would also have succeeded. But why= do you need that much complexity? Do you have it already with any other re= quest? > > Minor issues: > > This sentence: > > Furthermore, means to recover state in failure events must be supported, = but are not discussed in this document. > places a requirement on a relay (even though it's not using a 2119 MUST).= Is there some other document that defines this requirement that you can re= ference? > > Med: I'm not aware of any; but if there is one we can cite it. > > If not, the requirement should be discussed in this document. Alternati= vely, you could change the sentence to talk about the consequences of not h= aving a proprietary means for recovering state. > > Med: Will consider that option if you think this is really needed. > > Nits/editorial comments: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From johnsonhammond2@hushmail.com Sat Apr 27 10:08:47 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6371921F86F7 for ; Sat, 27 Apr 2013 10:08:47 -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 3pZo1AW69QlX for ; Sat, 27 Apr 2013 10:08:47 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1612B21F8644 for ; Sat, 27 Apr 2013 10:08:47 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id D33C830509 for ; Sat, 27 Apr 2013 17:08:46 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:08:46 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 9A98A14DBDE; Sat, 27 Apr 2013 17:08:46 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:08:46 -0400 To: dhcwg@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170846.9A98A14DBDE@smtp.hushmail.com> Subject: [dhcwg] Biggest Fake Conference in Computer Science X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:42:08 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From sunqi.thu@gmail.com Sun Apr 28 01:29:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AF921F97B8 for ; Sun, 28 Apr 2013 01:29:43 -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 L5pnzVGIPAod for ; Sun, 28 Apr 2013 01:29:42 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7013021F97B1 for ; Sun, 28 Apr 2013 01:29:42 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kq12so2435381pab.14 for ; Sun, 28 Apr 2013 01:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=ufKXovqfHXSJnxpQjyZvGblOrLMaNY+bzgMYSulkr6s=; b=N6JAtwx5TowV+NJQQdGS0ZJ599Px5QFiXw4vaD7AvaWEwAEL28kqvAmKDBJ+8m+8y+ Nb4dzQ0Noj5YNaWvpM3t1XpFmmfTn9EDx3t6VTbCGFqpzRaaUbi09kOjAd7ER4Bei8T2 3VzAllnIuEIkHKXXguFo/CLleO+h1s8xTTIBJZwM5mFMqftye826mW4zj6JegV073IRt wZIn7MNzAqGXDt965jobswNdACcMjs5Xbf48q2Yz1paCwLwo2V4T/2RjwuxKfUWou8VK 52trJ5GckUhc2el3yk8y6N3wmRFF4SX3ZOiJ0k9jN5XoumUxnjj4ImVqt7iAi9tS8UW/ dQdQ== X-Received: by 10.68.114.37 with SMTP id jd5mr65090701pbb.95.1367137782275; Sun, 28 Apr 2013 01:29:42 -0700 (PDT) Received: from [10.1.2.26] ([219.243.220.10]) by mx.google.com with ESMTPSA id to7sm20613705pab.0.2013.04.28.01.29.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 01:29:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1084) From: Qi Sun In-Reply-To: Date: Sun, 28 Apr 2013 16:29:28 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70C9508A-0C6C-448B-914C-D633D4352AAD@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AA1D675@nkgeml512-mbx.china.huawei.com> <1366964480.3011.2.camel@marcin-lenovo> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sun, 28 Apr 2013 04:47:09 -0700 Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 08:29:43 -0000 Dear all, I think this guideline is very useful. I support the WGLC on the = document. Best Regards, Qi Sun On 2013-4-26, at =E4=B8=8B=E5=8D=889:58, Kim Kinnear wrote: >=20 > I am also late, though not a co-author of this draft -- I'm just late. >=20 > I have read this document and support advancing it beyond last call. >=20 > Regards -- Kim >=20 > On Apr 26, 2013, at 4:21 AM, Marcin Siodelski wrote: >=20 >> I am one of the late joint co-authors of this draft. I also find this >> very important to have such a guideline document. I strongly support >> advancing this document. >>=20 >> Marcin >>=20 >> On Fri, 2013-04-26 at 10:32 +0800, GangChen wrote: >>> I support this WGLC. The draft already has stable and useful = contents. >>>=20 >>> BRs >>>=20 >>> Gang >>> 2013/4/26, Shwetha Bhandari (shwethab) : >>>> I have read and strongly support this work too. I find it very = useful >>>> especially when designing new DHCP options. >>>>=20 >>>> Shwetha >>>>=20 >>>> On 4/26/13 7:02 AM, "Sheng Jiang" wrote: >>>>=20 >>>>> As one of the late-join coauthor, I personally find such document = is very >>>>> useful for any readers who may create new DHC options. That's why = I >>>>> volunteered to wake this draft up and complete it. The current = version >>>>> has done a lot more work based on the previous version. It is real >>>>> easy-read and good guidelines for readers. I support to move it = forward. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Sheng >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On = Behalf >>>>>> Of Tomek Mrugalski >>>>>> Sent: Thursday, April 25, 2013 9:30 PM >>>>>> To: dhcwg@ietf.org >>>>>> Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - >>>>>> Respond by >>>>>> April 24 >>>>>>=20 >>>>>> On 09.04.2013 17:06, Bernie Volz (volz) wrote: >>>>>>> Folks, the authors of draft-ietf-dhc-option-guidelines-11, >>>>>>> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, = feel >>>>>>> it's >>>>>>> ready for a WGLC. There's been discussion and comment already, = but >>>>>> more >>>>>>> eyes on and a "final" review of this work are required to = advance it. >>>>>>>=20 >>>>>>> This document is critical as it provides guidance to others in = the IETF >>>>>>> that may not be DHCP "experts" when they need to write a DHCP = option >>>>>>> internet-draft. >>>>>> I strongly support this work. Having such a set of guidelines = published >>>>>> will make any review much easier. That will be especially handy = for >>>>>> drafts that are written outside of DHC WG. >>>>>>=20 >>>>>> I'm surprised that there's somewhat weak response to this last = call so >>>>>> far. Please, read this draft (it is easy read) and state you = opinion on >>>>>> it. >>>>>>=20 >>>>>> Disclaimer: Although I'm listed as co-author, I merely joined in = around >>>>>> a year ago. This document was created and developed by David = Hankins, >>>>>> who unfortunately is no longer active in DHC WG. >>>>>>=20 >>>>>> Tomek >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dhcwg mailing list >>>>>> dhcwg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>> _______________________________________________ >>>>> dhcwg mailing list >>>>> dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>=20 >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Sun Apr 28 18:01:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD2B21F9908 for ; Sun, 28 Apr 2013 18:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 9legPho3Gr8k for ; Sun, 28 Apr 2013 18:01:42 -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 8498321F98F4 for ; Sun, 28 Apr 2013 18:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1792; q=dns/txt; s=iport; t=1367197302; x=1368406902; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Eg+weYmPhRmAAxKGNNmwkBphZT365GEWUotMitFauSU=; b=hiT1Rr/uopCcrQFbQa1FJN2N1NSCKxINz3v4d8hcjFH00BCPy0QkwR9H c8pf9/fEnlUCyk+np+sPO+byMJmDTXz4nN0YaZhCqRDsAhR76A7EhTEiI nLoj4MkfuJiHIYzK77ECGotuq6d7UqeQ1bMEML2RKvd5GX/9N2ccaXEm7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAXFfVGtJV2Y/2dsb2JhbABSgwc2vkd/FnSCHwEBAQQBAQE3NBcGAQgRBAEBCxQJLgsUCQkBBBMIE4d7DJ09nwMEjU2BHD6CaGEDqEiBWIE5gig X-IronPort-AV: E=Sophos;i="4.87,569,1363132800"; d="scan'208";a="204078722" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 29 Apr 2013 01:01:42 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3T11g4k021199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Apr 2013 01:01:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sun, 28 Apr 2013 20:01:41 -0500 From: "Bernie Volz (volz)" To: DHC WG Thread-Topic: [dhcwg] WGLC Result - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28 Thread-Index: Ac5EdIc9sL7KsrWtReeOV3VI9sU2Bg== Date: Mon, 29 Apr 2013 01:01:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1851E904@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC Result - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 01:01:43 -0000 This document did NOT pass WGLC as there was no support for it and Ralph in= dicated that there were several IESG Discusses from several years ago (2009= ) that did not get addressed. Also, Barbara Stark commented about " alterna= tive solution that exists in BBF, for managed "RGs", for DHCPv6 options." The authors are encouraged to update the draft addressing the open issues a= nd try again. However, we will need additional support for this work if it is to pass a f= uture WGLC. - Tomek & Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Sunday, April 14, 2013 10:54 AM To: DHC WG Subject: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-0= 4-28 Folks, The authors of draft-ietf-dhc-container-opt-07 feel it's ready for WGLC. This draft was active around 2010, but then expired. It was revived (-06) in December 2012 and updated recently (-07). The last version is more= explicit about which options are not allowed in the container option. Please review the draft and indicate whether or not you feel it is ready to= be published. We have been getting very anemic responses to working group= last calls recently. Your response matters, so please do respond. Silent support is not enough. If not enough people voice their support, the= document will not advance. Simply saying "I support this work" is enough. = Providing detailed review is better, but not necessary. Bernie and I will evaluate consensus after April 28. At the time of this writing, there is no IPR reported against this draft. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Sun Apr 28 18:13:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADEC21F98C1 for ; Sun, 28 Apr 2013 18:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 w7fvxvDcMVTp for ; Sun, 28 Apr 2013 18:13:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 60D5921F98C0 for ; Sun, 28 Apr 2013 18:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13367; q=dns/txt; s=iport; t=1367198011; x=1368407611; h=from:to:subject:date:message-id:mime-version; bh=b9b7nZDcfpocksFE79YMfX6bjcZjcQcy09soJQ88kqg=; b=D6BRPCstQuwi6lkDO//pv0qJ+nDKXYMs4X8cb02xE1EHIoh5q6NJ9y0y GwbP2GG2Qwbw5A3YaSqpMckkfZMi2i1LCP77P4sj9BvJXO5+CaokJGQJz uwAATAdNsVQmAjK/XRdD1jpsjc7veXv4x+Yk6eE7G6gVz4p3zwOXVdjvB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoGAOjIfVGtJXHA/2dsb2JhbABSgkNENr5HfxZtB4IhAQQpBF4BAihWJgEEG4gOnVGfBo5pgyZhA6hIgxGCKA X-IronPort-AV: E=Sophos;i="4.87,569,1363132800"; d="scan'208,217";a="204040211" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 29 Apr 2013 01:13:31 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3T1DU4l019114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Apr 2013 01:13:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 28 Apr 2013 20:13:30 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Currently Outstanding WGLC and Adoption Calls Thread-Index: Ac5EdnXyQqRWwsOvSCifOpLzHFe05A== Importance: high X-Priority: 1 Date: Mon, 29 Apr 2013 01:13:29 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1851E98D@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.178] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1851E98Dxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Currently Outstanding WGLC and Adoption Calls X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 01:13:32 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1851E98Dxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Just a reminder that we have the following WGLCs outstanding: * draft-ietf-dhc-option-guidelines-11 - ends 2013-04-24 (extended a= few days per AD request - now ends 2013-04-30) * draft-ietf-dhc-dhcpv6-radius-opt-11 - ends 2013-05-02 (2nd WGLC b= ecause of late IPR) And the following WG Adoption Calls (to adopt the draft as WG item) outstan= ding: * draft-bhandari-dhc-access-network-identifier-04 - ends 2013-05-02 * draft-lemon-dhc-topo-conf-01 - ends 2013-05-02 * draft-rajtar-dhc-v4configuration-02 - ends 2013-05-08 Please comment! Your input to the WG is important!! - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1851E98Dxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

Just a reminder that we have the following WGLCs out= standing:

 

·         draft-ietf-dhc= -option-guidelines-11 – ends 2013-04-24 (extended a few days per AD r= equest – now ends 2013-04-30)

·         draft-ietf-dhc= -dhcpv6-radius-opt-11 - ends 2013-05-02 (2nd WGLC because of late IPR)

 

And the following WG Adoption Calls (to adopt the dr= aft as WG item) outstanding:

 

·         draft-bhandari= -dhc-access-network-identifier-04 - ends 2013-05-02

·         draft-lemon-dh= c-topo-conf-01 - ends 2013-05-02

·         draft-rajtar-d= hc-v4configuration-02 - ends 2013-05-08

 

Please comment! Your input to the WG is important= !!

 

-     &= nbsp;    Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1851E98Dxmbrcdx04ciscoc_-- From mohamed.boucadair@orange.com Sun Apr 28 22:59:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C74221F9D31; Sun, 28 Apr 2013 22:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbd+JyNPPzUc; Sun, 28 Apr 2013 22:59:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 768FB21F9D2F; Sun, 28 Apr 2013 22:59:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 26CC222C2FA; Mon, 29 Apr 2013 07:59:52 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id ED23C35C07A; Mon, 29 Apr 2013 07:59:51 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 29 Apr 2013 07:59:51 +0200 From: To: "Bernie Volz (volz)" , Robert Sparks Date: Mon, 29 Apr 2013 07:59:50 +0200 Thread-Topic: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 Thread-Index: AQHOQpnwLrlO/DVOGkmT6MAmTnOo8Zjpd9oAgAM8HYA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EC9B49B02@PUEXCB1B.nanterre.francetelecom.fr> References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> <517AA910.8030608@nostrum.com> <489D13FBFA9B3E41812EA89F188F018E1851CFD5@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1851CFD5@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.28.223919 Cc: "dhcwg@ietf.org" , General Area Review Team , "ietf@ietf.org" , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 05:59:57 -0000 Robert, Ted suggested a wording which is better than the one I proposed. I made the= following changes my local copy: (1) OLD: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). NEW: The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. (2) OLD: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. NEW: Furthermore, means to recover state in failure events (e.g., [RFC5460]) must be supported, but are not discussed in this document. Is this better? Cheers, Med >-----Message d'origine----- >De=A0: Bernie Volz (volz) [mailto:volz@cisco.com] >Envoy=E9=A0: samedi 27 avril 2013 06:24 >=C0=A0: Robert Sparks; BOUCADAIR Mohamed OLNC/OLN >Cc=A0: dhcwg@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf= - >dhc-triggered-reconfigure@tools.ietf.org >Objet=A0: RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >reconfigure-05 > >Robert: > >The reason to allow this is that otherwise client A will be unnecessarily >reconfigured many times. (It is also possible that a client might Renew on >its own just as this is happening and thus it can also be removed from the >Reconfigure.) > >I think the text should be cleaned up to indicate that allowing removal of >already reconfigured clients is recommended (to prevent unnecessary >reconfigures) when retransmitting the Reconfigure-Request. > >Note that if clients are added, that is not a retransmission but requires = a >"new" message (new XID). > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >Robert Sparks >Sent: Friday, April 26, 2013 12:19 PM >To: mohamed.boucadair@orange.com >Cc: dhcwg@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- >dhc-triggered-reconfigure@tools.ietf.org >Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >reconfigure-05 > >On 4/26/13 10:58 AM, mohamed.boucadair@orange.com wrote: >> Dear Robert, >> >> Thank you for the review. >> Please see inline. >> >> Cheers, >> Med >> ________________________________________ >> De : dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] de la part de >> Robert Sparks [rjsparks@nostrum.com] Date d'envoi : vendredi 26 avril >> 2013 17:42 =C0 : dhcwg@ietf.org; ietf@ietf.org; General Area Review >> Team; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org >> Objet : [dhcwg] Gen-art review: >> draft-ietf-dhc-triggered-reconfigure-05 >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> >.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-dhc-triggered-reconfigure-05 >> Reviewer: Robert Sparks >> Review Date: April 26, 2013 >> IETF LC End Date: May 6, 2013 >> IESG Telechat date: May 16, 2013 >> >> Summary: This draft is on the right track but has open issues, described >in >> the review. >> >> Major issues: >> >> Overall, this document is solid, but I think there is a bug in section >6.3. >> I could be wrong, but If I'm right, this paragraph: >> >> When retransmission is required, the relay may decide to correct the >content of RECONFIGURE-REQUEST message it issues (e.g., update the Client >Identifier list). This decision is local to the relay (e.g., it may be >based on observed events such as one or more clients were reconfigured on >their own). >> >> introduces a race-condition that could lead to an erroneous state. If a >relay's first message included client A, then the retransmission included >clients A and B, but that retransmission crosses with a success >RECONFIGURE-REPLY to the request that only included client A, the relay >will think it succeeded in asking A and B to be reconfigured. >> >> Med: This example does not apply for that text. >Really? What text constrains how you change what's in the retransmission? >> In fact, the example should be the other way around. Perhaps, this can >be made clearer if we change "(e.g., update the Client Identifier list)" t= o >"(e.g., remove a client from the Client Identifier list)". >If I understand you correctly, you need more than just changing a >parenthetical e.g.. I think you're saying that you are constraining the >message changes to be such that if anything earlier in the retransmission >sequence succeeded, the request in the retransmission would also have >succeeded. But why do you need that much complexity? Do you have it alread= y >with any other request? >> >> Minor issues: >> >> This sentence: >> >> Furthermore, means to recover state in failure events must be supported, >but are not discussed in this document. >> places a requirement on a relay (even though it's not using a 2119 MUST)= . >Is there some other document that defines this requirement that you can >reference? >> >> Med: I'm not aware of any; but if there is one we can cite it. >> >> If not, the requirement should be discussed in this document. >Alternatively, you could change the sentence to talk about the consequence= s >of not having a proprietary means for recovering state. >> >> Med: Will consider that option if you think this is really needed. >> >> Nits/editorial comments: > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From rjsparks@nostrum.com Mon Apr 29 06:45:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1621F9DAC; Mon, 29 Apr 2013 06:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.393 X-Spam-Level: X-Spam-Status: No, score=-101.393 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, SPF_PASS=-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 jErcWkT5NVVT; Mon, 29 Apr 2013 06:45:16 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C838C21F9DAD; Mon, 29 Apr 2013 06:45:15 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3TDjB1R056419 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 29 Apr 2013 08:45:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <517E796E.6040402@nostrum.com> Date: Mon, 29 Apr 2013 08:45:18 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> <517AA910.8030608@nostrum.com> <489D13FBFA9B3E41812EA89F188F018E1851CFD5@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EC9B49B02@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC9B49B02@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: "dhcwg@ietf.org" , General Area Review Team , "Bernie Volz \(volz\)" , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 13:45:19 -0000 On 4/29/13 12:59 AM, mohamed.boucadair@orange.com wrote: > Robert, > > Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy: > > (1) > > OLD: > When retransmission is required, the relay may decide to correct the > content of RECONFIGURE-REQUEST message it issues (e.g., update the > Client Identifier list). > > NEW: > The relay MAY remove clients from the client identifier list in > subsequent retransmissions, but MUST NOT add clients to the client > identifier list. > > (2) > > OLD: > Furthermore, means to recover state in failure events must be > supported, but are not discussed in this document. > > NEW: > Furthermore, means to recover state in failure events (e.g., > [RFC5460]) must be supported, but are not discussed in this document. > > Is this better? 1 is better. 2 is an improvement, I might say "such as" instead of e.g. to even more strongly avoid someone thinking you are _requiring_ implementation of RFC5460. Even then, it's still not clear whether you're trying to say "Something that doesn't do this is does not conform to this specification" or "Something that doesn't do this isn't as good a tool as it can be and may create a condition that operators and users will not like much." You chose not to use MUST in that sentence. Can you make it less likely that someone will assume you meant to? > > Cheers, > Med > > >> -----Message d'origine----- >> De : Bernie Volz (volz) [mailto:volz@cisco.com] >> Envoyé : samedi 27 avril 2013 06:24 >> À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN >> Cc : dhcwg@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- >> dhc-triggered-reconfigure@tools.ietf.org >> Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >> reconfigure-05 >> >> Robert: >> >> The reason to allow this is that otherwise client A will be unnecessarily >> reconfigured many times. (It is also possible that a client might Renew on >> its own just as this is happening and thus it can also be removed from the >> Reconfigure.) >> >> I think the text should be cleaned up to indicate that allowing removal of >> already reconfigured clients is recommended (to prevent unnecessary >> reconfigures) when retransmitting the Reconfigure-Request. >> >> Note that if clients are added, that is not a retransmission but requires a >> "new" message (new XID). >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >> Robert Sparks >> Sent: Friday, April 26, 2013 12:19 PM >> To: mohamed.boucadair@orange.com >> Cc: dhcwg@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- >> dhc-triggered-reconfigure@tools.ietf.org >> Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >> reconfigure-05 >> >> On 4/26/13 10:58 AM, mohamed.boucadair@orange.com wrote: >>> Dear Robert, >>> >>> Thank you for the review. >>> Please see inline. >>> >>> Cheers, >>> Med >>> ________________________________________ >>> De : dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] de la part de >>> Robert Sparks [rjsparks@nostrum.com] Date d'envoi : vendredi 26 avril >>> 2013 17:42 À : dhcwg@ietf.org; ietf@ietf.org; General Area Review >>> Team; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org >>> Objet : [dhcwg] Gen-art review: >>> draft-ietf-dhc-triggered-reconfigure-05 >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> >> > .ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-dhc-triggered-reconfigure-05 >>> Reviewer: Robert Sparks >>> Review Date: April 26, 2013 >>> IETF LC End Date: May 6, 2013 >>> IESG Telechat date: May 16, 2013 >>> >>> Summary: This draft is on the right track but has open issues, described >> in >>> the review. >>> >>> Major issues: >>> >>> Overall, this document is solid, but I think there is a bug in section >> 6.3. >>> I could be wrong, but If I'm right, this paragraph: >>> >>> When retransmission is required, the relay may decide to correct the >> content of RECONFIGURE-REQUEST message it issues (e.g., update the Client >> Identifier list). This decision is local to the relay (e.g., it may be >> based on observed events such as one or more clients were reconfigured on >> their own). >>> introduces a race-condition that could lead to an erroneous state. If a >> relay's first message included client A, then the retransmission included >> clients A and B, but that retransmission crosses with a success >> RECONFIGURE-REPLY to the request that only included client A, the relay >> will think it succeeded in asking A and B to be reconfigured. >>> Med: This example does not apply for that text. >> Really? What text constrains how you change what's in the retransmission? >>> In fact, the example should be the other way around. Perhaps, this can >> be made clearer if we change "(e.g., update the Client Identifier list)" to >> "(e.g., remove a client from the Client Identifier list)". >> If I understand you correctly, you need more than just changing a >> parenthetical e.g.. I think you're saying that you are constraining the >> message changes to be such that if anything earlier in the retransmission >> sequence succeeded, the request in the retransmission would also have >> succeeded. But why do you need that much complexity? Do you have it already >> with any other request? >>> Minor issues: >>> >>> This sentence: >>> >>> Furthermore, means to recover state in failure events must be supported, >> but are not discussed in this document. >>> places a requirement on a relay (even though it's not using a 2119 MUST). >> Is there some other document that defines this requirement that you can >> reference? >>> Med: I'm not aware of any; but if there is one we can cite it. >>> >>> If not, the requirement should be discussed in this document. >> Alternatively, you could change the sentence to talk about the consequences >> of not having a proprietary means for recovering state. >>> Med: Will consider that option if you think this is really needed. >>> >>> Nits/editorial comments: >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Apr 29 07:18:36 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3121F9D80; Mon, 29 Apr 2013 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id donM72n4hjJv; Mon, 29 Apr 2013 07:18:35 -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 3C0A921F9D8C; Mon, 29 Apr 2013 07:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8804; q=dns/txt; s=iport; t=1367245115; x=1368454715; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=79UA9FLZu0g3FxXvLo4Lkql6GqmmOh0mD/nUOcM1nj8=; b=WofcX8Csqxt7HQophfHOch7vXGgkL+Fi4pD18TI3tOkhKCrl/nEHZSBB 7ykO45ILrIviQE5OM5vpv+BfCcnuZeCcr87wqChEIFN1agthDP7zZR+CN LL+X7b4pq9WWkydEQjz854u4GYqH2l0WaX/rM9geXmMfXdg5VOGwJXDcv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALCAflGtJXG8/2dsb2JhbABTgwc2vkCBAxZ0gh8BAQEEAQEBawsMBAIBCA4DAwEBAQEKHQcnCxQJCAIEAQ0FCBOHewy7RI1uezEHBoJoYQOIWoNFhzCEdYVfiiWDEYFrPQ X-IronPort-AV: E=Sophos;i="4.87,574,1363132800"; d="scan'208";a="204307575" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 29 Apr 2013 14:18:34 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3TEIY57002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 14:18:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 09:18:34 -0500 From: "Bernie Volz (volz)" To: Robert Sparks , "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 Thread-Index: AQHORN/GDK4q6qizh0K41HkFQ0/z/ZjtOjmg Date: Mon, 29 Apr 2013 14:18:33 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1851F76A@xmb-rcd-x04.cisco.com> References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> <517AA910.8030608@nostrum.com> <489D13FBFA9B3E41812EA89F188F018E1851CFD5@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EC9B49B02@PUEXCB1B.nanterre.francetelecom.fr> <517E796E.6040402@nostrum.com> In-Reply-To: <517E796E.6040402@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.178] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , General Area Review Team , "ietf@ietf.org" , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:18:36 -0000 FYI - Stable storage or some kind of redundancy solution may be another way= to recover state. So, I don't think there is a hard requirement for RFC 54= 60. I don't think there is a strong reason to avoid e.g., it is "for example" s= o it is only one of many possible. And "such as" is basically saying the sa= me thing. --- But then we come to why this is even important ... The original text was: This setup assumes the relay has a record of the client, so that it has enough information to send the Reconfigure-Request message to the server. How the state is recorded in the relay is out of scope. Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. I'm a bit skeptical why this draft even brings the 'recover state' up. Yes,= the relay does need to record the client in order to initiate a Reconfigur= e-Request. But I think the sentence "Furthermore, means to recover state in= failure events must be supported, but are not discussed in this document."= is not needed. Sure, if the relay has no way of recovering this state, tra= ffic to/from clients will likely not work and certainly if the relay is rec= onfigured, it will be unable to generate a Reconfigure-Request. But I don't= really see this draft needing this requirement. Reconfigure-request could = still work until the state is lost. And if the state is lost, there is a lo= t more than is potentially broken. But I don't really see this as a big issue and the "must" is the lower-case= variant anyway. - Bernie -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Monday, April 29, 2013 9:45 AM To: mohamed.boucadair@orange.com Cc: Bernie Volz (volz); dhcwg@ietf.org; General Area Review Team; ietf@ietf= .org; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfig= ure-05 On 4/29/13 12:59 AM, mohamed.boucadair@orange.com wrote: > Robert, > > Ted suggested a wording which is better than the one I proposed. I made t= he following changes my local copy: > > (1) > > OLD: > When retransmission is required, the relay may decide to correct the > content of RECONFIGURE-REQUEST message it issues (e.g., update the > Client Identifier list). > > NEW: > The relay MAY remove clients from the client identifier list in > subsequent retransmissions, but MUST NOT add clients to the client > identifier list. > > (2) > > OLD: > Furthermore, means to recover state in failure events must be > supported, but are not discussed in this document. > > NEW: > Furthermore, means to recover state in failure events (e.g., > [RFC5460]) must be supported, but are not discussed in this document. > > Is this better? 1 is better. 2 is an improvement, I might say "such as" instead of e.g. to even more str= ongly avoid someone thinking you are _requiring_ implementation of RFC5460.= Even then, it's still not clear whether you're trying to say "Something that doesn't do this is does not conform to this specification" or "Something that doesn't do this isn't as good a tool as it can be and may c= reate a condition that operators and users will not like much." You chose not to use MUST in that sentence. Can you make it less likely tha= t someone will assume you meant to? > > Cheers, > Med > > >> -----Message d'origine----- >> De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : samedi 27=20 >> avril 2013 06:24 =C0 : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc :=20 >> dhcwg@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-=20 >> dhc-triggered-reconfigure@tools.ietf.org >> Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >> reconfigure-05 >> >> Robert: >> >> The reason to allow this is that otherwise client A will be=20 >> unnecessarily reconfigured many times. (It is also possible that a=20 >> client might Renew on its own just as this is happening and thus it=20 >> can also be removed from the >> Reconfigure.) >> >> I think the text should be cleaned up to indicate that allowing=20 >> removal of already reconfigured clients is recommended (to prevent=20 >> unnecessary >> reconfigures) when retransmitting the Reconfigure-Request. >> >> Note that if clients are added, that is not a retransmission but=20 >> requires a "new" message (new XID). >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Robert Sparks >> Sent: Friday, April 26, 2013 12:19 PM >> To: mohamed.boucadair@orange.com >> Cc: dhcwg@ietf.org; General Area Review Team; ietf@ietf.org;=20 >> draft-ietf- dhc-triggered-reconfigure@tools.ietf.org >> Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >> reconfigure-05 >> >> On 4/26/13 10:58 AM, mohamed.boucadair@orange.com wrote: >>> Dear Robert, >>> >>> Thank you for the review. >>> Please see inline. >>> >>> Cheers, >>> Med >>> ________________________________________ >>> De : dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] de la part de=20 >>> Robert Sparks [rjsparks@nostrum.com] Date d'envoi : vendredi 26=20 >>> avril >>> 2013 17:42 =C0 : dhcwg@ietf.org; ietf@ietf.org; General Area Review=20 >>> Team; draft-ietf-dhc-triggered-reconfigure@tools.ietf.org >>> Objet : [dhcwg] Gen-art review: >>> draft-ietf-dhc-triggered-reconfigure-05 >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on=20 >>> Gen-ART, please see the FAQ at >>> >>> >> > .tools .ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> Please resolve these comments along with any other Last Call=20 >>> comments you may receive. >>> >>> Document: draft-ietf-dhc-triggered-reconfigure-05 >>> Reviewer: Robert Sparks >>> Review Date: April 26, 2013 >>> IETF LC End Date: May 6, 2013 >>> IESG Telechat date: May 16, 2013 >>> >>> Summary: This draft is on the right track but has open issues,=20 >>> described >> in >>> the review. >>> >>> Major issues: >>> >>> Overall, this document is solid, but I think there is a bug in=20 >>> section >> 6.3. >>> I could be wrong, but If I'm right, this paragraph: >>> >>> When retransmission is required, the relay may decide to correct the >> content of RECONFIGURE-REQUEST message it issues (e.g., update the=20 >> Client Identifier list). This decision is local to the relay (e.g.,=20 >> it may be based on observed events such as one or more clients were=20 >> reconfigured on their own). >>> introduces a race-condition that could lead to an erroneous state.=20 >>> If a >> relay's first message included client A, then the retransmission=20 >> included clients A and B, but that retransmission crosses with a=20 >> success RECONFIGURE-REPLY to the request that only included client A,=20 >> the relay will think it succeeded in asking A and B to be reconfigured. >>> Med: This example does not apply for that text. >> Really? What text constrains how you change what's in the retransmission= ? >>> In fact, the example should be the other way around. Perhaps,=20 >>> this can >> be made clearer if we change "(e.g., update the Client Identifier=20 >> list)" to "(e.g., remove a client from the Client Identifier list)". >> If I understand you correctly, you need more than just changing a=20 >> parenthetical e.g.. I think you're saying that you are constraining=20 >> the message changes to be such that if anything earlier in the=20 >> retransmission sequence succeeded, the request in the retransmission=20 >> would also have succeeded. But why do you need that much complexity?=20 >> Do you have it already with any other request? >>> Minor issues: >>> >>> This sentence: >>> >>> Furthermore, means to recover state in failure events must be=20 >>> supported, >> but are not discussed in this document. >>> places a requirement on a relay (even though it's not using a 2119 MUST= ). >> Is there some other document that defines this requirement that you=20 >> can reference? >>> Med: I'm not aware of any; but if there is one we can cite it. >>> >>> If not, the requirement should be discussed in this document. >> Alternatively, you could change the sentence to talk about the=20 >> consequences of not having a proprietary means for recovering state. >>> Med: Will consider that option if you think this is really needed. >>> >>> Nits/editorial comments: >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Apr 29 09:38:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3735621F9E07; Mon, 29 Apr 2013 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDlHR718wayO; Mon, 29 Apr 2013 09:38:05 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEDA21F9E01; Mon, 29 Apr 2013 09:38:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUX6h7C8MLrDsUSNolbSkLQEXAJXa3/MR@postini.com; Mon, 29 Apr 2013 09:38:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8A57D1B815E; Mon, 29 Apr 2013 09:38:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7BE84190061; Mon, 29 Apr 2013 09:38:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 09:38:04 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 Thread-Index: AQHORORy+jlCE9D1eEC77pV047+J55jt22OA Date: Mon, 29 Apr 2013 16:38:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775166969@mbx-01.win.nominum.com> References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36EC9D2A2BD@PUEXCB1B.nanterre.francetelecom.fr> <517AA910.8030608@nostrum.com> <489D13FBFA9B3E41812EA89F188F018E1851CFD5@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EC9B49B02@PUEXCB1B.nanterre.francetelecom.fr> <517E796E.6040402@nostrum.com> <489D13FBFA9B3E41812EA89F188F018E1851F76A@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1851F76A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0EEDAECDCBFCE341849C5B85D1C939EA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , General Area Review Team , "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" , "dhcwg@ietf.org" , Robert Sparks Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:38:06 -0000 On Apr 29, 2013, at 10:18 AM, "Bernie Volz (volz)" wrote: > But I don't really see this as a big issue and the "must" is the lower-ca= se variant anyway. There's a big debate about whether this makes any difference. It's genera= lly thought to be better not to say must if you don't mean MUST. I think the idea of just saying e.g. is the right thing, and stable storage= and bulk leasequery would be two really great examples to use. From dhankins@google.com Mon Apr 29 11:28:10 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDC221F9AB7 for ; Mon, 29 Apr 2013 11:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tGDAruFbaUtg for ; Mon, 29 Apr 2013 11:28:09 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A921F9AB5 for ; Mon, 29 Apr 2013 11:28:08 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id to1so7821772ieb.11 for ; Mon, 29 Apr 2013 11:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FQiNx60DMc6Z8MvhPmYJOTHuZf1ZzoxADcC5I0ynhEg=; b=OYeughGuV7F+h4XwM4KcQIQi6F2aMyjHOmMvk9RfE9OIH6oxB+d2R7iteeTnG3md5R 2XM8MJbfgoWeoyaG5iwBEIOO/X+CmsnINl3+QLuiV6rppqQFzHZs2t7OCsyW9/wMCKmO jKwbpK44uL5ITNu4oO6baohYBkbwdYZ0ZT1IL68oMOfIJNVIunXh0EoUnaNLr9KqG0Tq /prxGvHYwhIwxzjvFi5R3D4Mb36sAbaIwxzP5NQKBKv16NVprrtnoenUg9VOJUivRdNs Zn5q7lxWIai0+nncjQO5DgjYmQNGFhyjXlWNfzauGzi/aaDg9DglIQboeQnDdx2McARd tXZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FQiNx60DMc6Z8MvhPmYJOTHuZf1ZzoxADcC5I0ynhEg=; b=VSDOOUTBsneXaaAX5chiw9k4BxfhvTsDktWTSM42UXzUwahSJNf+hQLwlX4Vbp5fto aFOR/Jol32AHQG4xn1jmMtdPJSSo7eXkhYJYH3vVmbyWth+Nyy9Bm5DAl6eRPmXpDl// lZCVQfL+vif6I4+mWmjRPDfVGNjyhefku/yuh0gaODO4ABJXixAVg6iSknJ+Rm6HxC5Y /MQtEBXLUvKrhaMhNhwSVcYP44SDLudsr2lWFNgbK6K8yYbrUQoHforwUYVCkYf8NBkJ 61AZOvg930bokLdhoIZUbua9uQsrZ/YT7bQiQi6LvKz+zSTp6kNAPfRxaTJBDnsH8QB5 cK1A== MIME-Version: 1.0 X-Received: by 10.50.7.66 with SMTP id h2mr1546802iga.31.1367260088436; Mon, 29 Apr 2013 11:28:08 -0700 (PDT) Received: by 10.64.68.231 with HTTP; Mon, 29 Apr 2013 11:28:08 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C108@PUEXCB1B.nanterre.francetelecom.fr> References: <51640E5C.4020900@gmail.com> <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C108@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 29 Apr 2013 11:28:08 -0700 Message-ID: From: David Hankins To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=089e0122edb2e33ab204db840bd2 X-Gm-Message-State: ALoCoQkEa9Hl5uyYn+G0Y+0xSNoFkgoF+A9KuY/q1+LwWZtwO1yfgvasWr6MJyT21vqUDYgxr9C/4IiuFEFWb8DvSaGG2UenPrsr1EVfp2E3OUwdU7tw/XSdrtaYx1p5igw96yhwu9IT4gd/ul5V25HycikGRzQus1xh567t9/yFmx1Hvt2zy6T+6ShDOlhSlK0M7ItKrwJx Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 18:28:10 -0000 --089e0122edb2e33ab204db840bd2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Med, I believe the draft as written is consistent with the publishing of RFC 6334, and summarizes most of the points you make in dhc-address-name-encoding. But your point in section 2.2.2 is hard to understand. It's equivalent to configure the regionalized FQDN in the DHCP server or client; the same name will be resolved from the same (separate administrative domain) DNS server which is authoritative. That is to say, whereas Client A and Client B will resolve separate names if given separate names, Server A will resolve separate names for Client A and Client B and deliver to them the results of those specific resolutions. The only differences are that 1) regional teams do not get a DNS packet with a source address specific to the client which they can use to inform load balancing decisions, so this reduces to be the same as your point in 2.2.3 and 2) the name can not be overloaded (where e.g. "foo-server.orange.com." is resolved differently depending on which recursive resolver is used - depending on something similar to what BIND calls "views") - but this again reduces to your point in 2.2.3 as it is simply a second level of domain name load balancing. I can only guess one possible misunderstanding on your part; RFC 3315 FQDN format options convey Fully Qualified Domain Names. This is a name including an explicit zero length label indicating the DNS Root. DNS search paths are not applied to names conveyed by RFC 3315 format names, except as a non-standard extension of the protocol (or by this detail simply being overlooked by implementers). So one does not gain any additional ability to handoff between administrative domains by the ability to configure a "foo-server" server name in an DHCP option and "thoseguys.orange.com" in domain search path separately. There is no significant DHCP server configuration complexity reduction since all servers I'm familiar with (excepting "embedded device" / zeroconf servers etc.) provide a means to concatenate names hierarchically. And one of the points you missed in your draft is that the server performing the recursive resolution to populate an IP address option for the client most likely locally caches the lookup internally (as opposed to externally). This changes the game from a zero-sum latency movement into a latency net win, obeying DNS TTL semantics. So in my opinion it remains superior to use a raw IP address format when there's no compelling reason to promote the option under consideration to a FQDN. I believe, after some effort, the participants of the softwires wg, yourself included, eventually justified that promotion for the publication of RFC 6334. Undertaking that effort to extract such requirements is important; we need to produce the lightest and fastest protocols we can. "Use What You Need." It's my opinion that the current text conveys that message. At some points in the text, we also underscore that these are guidelines, and it is not intended for the document to constrain future protocol development. It's also my opinion that RFC's 3361, and 3319 are casualties of the organizational failure to clearly communicate the constraints and requirements. I'm not familiar with the other RFC numbers, but I'm guessing a similar problem prevailed. On Fri, Apr 12, 2013 at 5:12 AM, wrote: > Dear all, > > I read this version. Thanks for the work. > > IMHO, > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#section-8d= oes not reflect the consensus of the WG on these matters. Especially, it > does not reflect what has been discussed during the call for adoption for > http://datatracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding= / > . > > Saying IP Address is superior to FQDN is just not that trivial to say. It > is not a universal statement and it makes deployment assumptions. I don't > want to reiterate what have been discussed for > draft-boucadair-dhc-address-name-encoding, archives are there to extract > the exact position of the wg. > > The text in Section 8 still assume DNS is the only available name > resolution library; this is not anymore true. Section 2 of > draft-boucadair-dhc-address-name-encoding provides a much more balanced > comparison. > > Instead of picking a winner (IP Address vs. FQDN), it is more valuable to > investigates ways to accommodates operational needs rather than imposing = a > deployment choice for entities deploying servers and making use of a give= n > option. > > Cheers, > Med > > >-----Message d'origine----- > >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part d= e > >Bernie Volz (volz) > >Envoy=E9 : mardi 9 avril 2013 17:06 > >=C0 : dhcwg@ietf.org > >Objet : [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by > >April 24 > > > >Folks, the authors of draft-ietf-dhc-option-guidelines-11, > >http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it'= s > >ready for a WGLC. There's been discussion and comment already, but more > >eyes on and a "final" review of this work are required to advance it. > > > >This document is critical as it provides guidance to others in the IETF > >that may not be DHCP "experts" when they need to write a DHCP option > >internet-draft. > > > >At the time of this writing, there is no IPR reported against this draft= . > > > >Please review the draft and indicate whether or not you feel it is ready > >to be published. Your response matters to the process, so please do > >respond. > > > >As Tomek is an author, I will evaluate consensus after April 24, 2013. > > > >Thanks! > > > >- Bernie > > > > > >_______________________________________________ > >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 > --=20 David W. Hankins SRE - Systems Engineer Google, Inc. :x --089e0122edb2e33ab204db840bd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Med, I believe the draft as written is consistent with the= publishing of RFC 6334, and summarizes most of the points you make in dhc-= address-name-encoding.

But your point in section 2= .2.2 is hard to understand. =A0It's equivalent to configure the regiona= lized FQDN in the DHCP server or client; the same name will be resolved fro= m the same (separate administrative domain) DNS server which is authoritati= ve. =A0That is to say, whereas Client A and Client B will resolve separate = names if given separate names, Server A will resolve separate names for Cli= ent A and Client B and deliver to them the results of those specific resolu= tions. =A0The only differences are that 1) regional teams do not get a DNS = packet with a source address specific to the client which they can use to i= nform load balancing decisions, so this reduces to be the same as your poin= t in 2.2.3 and 2) the name can not be overloaded (where e.g. "foo-server.orange.com." is resol= ved differently depending on which recursive resolver is used - depending o= n something similar to what BIND calls "views") - but this again = reduces to your point in 2.2.3 as it is simply a second level of domain nam= e load balancing.

I can only guess one possible misunderstand= ing on your part; RFC 3315 FQDN format options convey Fully Qualified Domai= n Names. =A0This is a name including an explicit zero length label indicati= ng the DNS Root. =A0DNS search paths are not applied to names conveyed by R= FC 3315 format names, except as a non-standard extension of the protocol (o= r by this detail simply being overlooked by implementers).

So one does not gain any additional ability = to handoff between administrative domains by the ability to configure a &qu= ot;foo-server" server name in an DHCP option and "thoseguys.orange.com" in domain search pa= th separately. =A0There is no significant DHCP server configuration complex= ity reduction since all servers I'm familiar with (excepting "embe= dded device" / zeroconf servers etc.) provide a means to concatenate n= ames hierarchically.


And one of the points you missed i= n your draft is that the server performing the recursive resolution to popu= late an IP address option for the client most likely locally caches the loo= kup internally (as opposed to externally). =A0This changes the game from a = zero-sum latency movement into a latency net win, obeying DNS TTL semantics= .


So in my opinion it remains superior to = use a raw IP address format when there's no compelling reason to promot= e the option under consideration to a FQDN. =A0I believe, after some effort= , the participants of the softwires wg, yourself included, eventually justi= fied that promotion for the publication of RFC 6334. =A0Undertaking that ef= fort to extract such requirements is important; we need to produce the ligh= test and fastest protocols we can.

"Use What You Need."
<= div style>
It's my opinion that the current text co= nveys that message. =A0At some points in the text, we also underscore that = these are guidelines, and it is not intended for the document to constrain = future protocol development.

It's also my opinion that RFC's 336= 1, and 3319=A0are casualties of the organizational failure to clearly commu= nicate the constraints and requirements. =A0I'm not familiar with the o= ther RFC numbers, but I'm guessing a similar problem prevailed.


On Fri,= Apr 12, 2013 at 5:12 AM, <mohamed.boucadair@orange.com>= ; wrote:
Dear all,

I read this version. Thanks for the work.

IMHO, http://tools.ietf.org/html/draft-ietf-dhc= -option-guidelines-11#section-8 does not reflect the consensus of the W= G on these matters. Especially, it does not reflect what has been discussed= during the call for adoption for http://data= tracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding/.

Saying IP Address is superior to FQDN is just not that trivial to say. It i= s not a universal statement and it makes deployment assumptions. I don'= t want to reiterate what have been discussed for draft-boucadair-dhc-addres= s-name-encoding, archives are there to extract the exact position of the wg= .

The text in Section 8 still assume DNS is the only available name resolutio= n library; this is not anymore true. Section 2 of draft-boucadair-dhc-addre= ss-name-encoding provides a much more balanced comparison.

Instead of picking a winner (IP Address vs. FQDN), it is more valuable to i= nvestigates ways to accommodates operational needs rather than imposing a d= eployment choice for entities deploying servers and making use of a given o= ption.

Cheers,
Med

>-----Message d'origine-----
>De=A0: dhcwg-bounces@ietf.org= [mailto:dhcwg-bounces@ietf.o= rg] De la part de
>Bernie Volz (volz)
>Envoy=E9=A0: mardi 9 avril 2013 17:06
>=C0=A0: dhcwg@ietf.org
>Objet=A0: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond = by
>April 24
>
>Folks, the authors of draft-ietf-dhc-option-guidelines-11,
>http://tools.ietf.org/html/draft-ietf-dhc-option-guid= elines-11, feel it's
>ready for a WGLC. =A0There's been discussion and comment already, b= ut more
>eyes on and a "final" review of this work are required to adv= ance it.
>
>This document is critical as it provides guidance to others in the IETF=
>that may not be DHCP "experts" when they need to write a DHCP= option
>internet-draft.
>
>At the time of this writing, there is no IPR reported against this draf= t.
>
>Please review the draft and indicate whether or not you feel it is read= y
>to be published. Your response matters to the process, so please do
>respond.
>
>As Tomek is an author, I will evaluate consensus after April 24, 2013.<= br> >
>Thanks!
>
>- =A0 =A0 =A0Bernie
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
=
David W. Hankins
SRE - Systems Engineer
Google, Inc.
:x
--089e0122edb2e33ab204db840bd2-- From dhankins@google.com Mon Apr 29 11:33:29 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E9121F9AF3 for ; Mon, 29 Apr 2013 11:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Odnlqp4r1x3x for ; Mon, 29 Apr 2013 11:33:26 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01221F9AF2 for ; Mon, 29 Apr 2013 11:33:26 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id bn7so7733475ieb.13 for ; Mon, 29 Apr 2013 11:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VhL01mRbSstcQto3Pkm3F6APAnNzmvKBgMHwpy3lS7Q=; b=fUIrqPCLXCkOHfEt11gw4zb0l9zeKFwvwhfFRd70F20bdyCiuJalDjCbS6QpGT0rVF ovLf+vTEIIAaMUCA1QcSiBCAF20Dr5N3yejNgnJjTH9jh5uh1t4sgwpU6Q8AdKRv++gV n5G8z7ScLy7dzAwvwW7QNz/iZgNqRq3I/8/RCHaH6WLaIm9bfMzJh7GoVc8462QyAwBa 5HEeIExBStaOHu8Q24vl9KlojstjfxWE6qOZVAyiKNBA2K2NyyIytU3r4rU0grjJzlFt yYyB/T7Iiv2SKihrfSYXAru6Xpz3zdnFrkgxNa8gNtD2GEhtbtV+oR2rofCx+KvjbaIi akkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=VhL01mRbSstcQto3Pkm3F6APAnNzmvKBgMHwpy3lS7Q=; b=OpuPxIOWnIhP7vnKqdwndzzBxzTouFBFhq9Y+BIehe8L8oxVmh34Aj9iPYniVqvkpo 2a/suOqSWu8lfGRC6vJowoxaH2Y2YQ5pU8rL8HRnmACXKuH2x4ISBTdRhB/9tgpuqqV/ +NIRrZ+vy0eOwsnBdh9rSu1dRlyhy/PFVyMQEhPemGPzGAHGgvnB8xzCaaov/hJWUZfo 1D3Rsn1iAELmo6HhNASZReeWRC9aprY5yiDa49P13C4ZEvVOAZnllX6kS7FrGGNICc6i DtiLYdkNjF2Wo00orDpVJ9w2UrVUqC5m5mViMq12f0juUWAwauzuPEhDHnY5AnrunX1/ k4OA== MIME-Version: 1.0 X-Received: by 10.50.7.66 with SMTP id h2mr1558116iga.31.1367260406132; Mon, 29 Apr 2013 11:33:26 -0700 (PDT) Received: by 10.64.68.231 with HTTP; Mon, 29 Apr 2013 11:33:26 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18504BC7@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E18504BC7@xmb-rcd-x04.cisco.com> Date: Mon, 29 Apr 2013 11:33:26 -0700 Message-ID: From: David Hankins To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e0122edb2d2c14f04db841e00 X-Gm-Message-State: ALoCoQlfCxOn9gwjK+fSd4rF88A17GYQ6xtFPn9+5GEQaaVvC4Oeh8CXOa0hK9aHxnRld+2Y13a5hr7sNL3l73ZOZsSYH5mPTno8xOniXqHIPeqWoril24jOzspFkVTQJL1Riw2t8Tt1qIAwYq4wUAM1BF4mza0bGhZhxyUub+jjDVcpu8wORlgDgw3+3i97daA6jdfc7daI Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 18:33:29 -0000 --089e0122edb2d2c14f04db841e00 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 14, 2013 at 1:13 PM, Bernie Volz (volz) wrote: > NOTE: WG co-chair hat OFF ... these are my comments as an individual > "member" of the WG. > > I fully support this work and would like to see it advance. And I have > done a somewhat careful review with the comments below. > > 1. I think the "updates RFC 3315" in the header and also in the Abstract > is wrong and should be removed. There is nothing in this document that > specifically changes anything in RFC 3315. > > I think an earlier version of the draft had some text that proposed to clarify some point. I suspect instead I was absolved of my own misunderstanding on the point, but this wasn't removed. > 2. In section 3 - add text in brackets: > > accessing the external Internet via local assist services that [the] > network must also provide (such as domain name servers, or routers). > > ... > > this is one [of the] main reason[s] for the use of DHCPv6 in corporate > enterprises. > > 3. In section 5 - replace/add text in brackets: > > This [means] that implementations will [likely] be able to reuse code > paths > designed to support the other options. > > Another choice would be "This assumes that implementations will be able > ...". > > Drop the last sentence as it is not true: "It is only a list of option > format fragments which are used in two or more options." > > 4. Section 5.1: > > For: > o DHCPv6 server unicast address [RFC3315] > You need to also add "(a single address only)". > > 5. Section 5.3: > > Sometimes there is a need to convey [a/an] IPv6 prefix. The > information to > be carried by [such] an option includes the 128-bit IPv6 prefix together > > Wonder whether the equation should be: > ( + 7) /8 > As written, it may be misevaluated as division has higher preference than > addition (usually). We could further clarify the integer portion is used, > but I think that is clear as you can't have 6.5 octets. > > In the example, prefix-len should be prefix6-len: > > For example, the prefix 2001:db8::/60 would be encoded with an > option-length of 9, prefix6-len would be set to 60, the ipv6-prefix > would be 8 octets and would contains octets 20 01 0d b8 00 00 00 00. > > And replace the last sentence paragraph with: > > It should be noted that the IAPREFIX option defined by [RFC3633] > uses a constant length prefix. The concern about option length was > not well understood at the time of its publication. > > 6. Section 5.7 - I wonder whether it is worth to remind future writers > they MUST document the allowed encoding for this data. > > 7. Section 5.8 - I wonder whether it is worth to point out that this > really is a specific encoding instances of section 5.7, and in this case > the encode can also support multiple instances as the DNS wire encoded > format allows on to determine the end of a FQDN (because of the 0 "." > field). > > 8. Section 6: > > The following is a bit odd ... > > Therefore the conditional formatting requires new code to > be written, as well as introduces an implementation problem; as it > requires that all speakers implement all current and future > conditional formats. > > Conditional formatting is not recommended, except in cases where the > DHCPv6 option has already been deployed experimentally, and all but > one conditional format is deprecated. > > Can we replace this with: > > Conditional formatting requires new code to be written and complicates > future interoperability should new conditional formats be added; and > existing code has to ignore conditional formats that it does not support. > > Do we even want to suggest that "deployed experimentally" is useful? It is > an experiment so why would the 'official' IETF option use it? I would just > suggest not to go there - I don't want someone arguing 'well, I > experimented in my network using option 55555 with this conditional format > and this document lets me keep that conditional format." > > 9. Section 8. > > Reword: > > Section 7), so one of them must be chosen. This section is intended > as a help to make an informed decision in that regard. > > To: > > Section 7), so one of them must be chosen. This section is intended > to help make an informed decision in that regard. > > And also: > > FQDN imposes [a] number of additional failure modes and issues that > should be dealt with: > > And I still have concerns about #4 and #7 in this list. They don't really > make that much sense as written. > > Perhaps for 4 the intent was: > > 4. The client has to determine for which address families DNS is > queried? A or AAAA records or both? And if both, which is preferred? Client > implementations are encouraged to follow [RFC 6555] if both address > families are possible. > > For 7, I think this issue refers to encoding that is not DNS wire format - > as I don't understand what the issue is for IDNs for DNS wire encoding? But > this goes back to my issue with #6 for Section 5.7 that documenting the > encoding is important. > > I suspect this issue 7 goes back to when UTF-8 or ASCII was intended as a > possible 'string' encoding (as then addresses in string format could be > sent). The text in Section 8 never really discussed 'FQDN' encoding, but > there really is the question as to what does "FQDN" mean? I don't think we > generally mean it to be an ASCII representation of a v4 or v6 address. > > So perhaps this means that 'FQDN' is a bad term used in this section or > that we need additional text to discuss this alternate form for a "string" > encoding of an ASCII representation for a v4/v6 address or a FQDN. (The 2nd > paragraph in this section 8 starts out with "On the specific subject of > desiring to configure a value using a FQDN instead of a binary IP address" > - yet Med's original proposal wasn't a choice between the two but an > ENCODING that allowed an FQDN or "ascii" address. So perhaps we have not > really answered his quest for that? (Which may be why he sent his response > to this WGLC.) > > Perhaps for 7 in the list, remove it and add a new paragraph to end of the > section (feel free to edit and extend): > > Some may be tempted to use a "string" encoding which would allow the > string representation of an address or a domain name. However, this MUST be > avoided as it has many potential security and implementation issues, some > of which are: > 1. How is this data encoded? Especially consider International Domain > Names and non-ASCII characters in domain names. > 2. How is this data validated? While it is easy to determine whether the > string representation of an IPv6 (or IPv4) address is specified, it is more > difficult to validate domain names as valid FQDNs. And, is a terminal "dot" > assumed for the domain name or are relative names allowed (if so, this of > course raises the question of the search list being used by the client). > > 10. Section 9: > > From the implementation perspective, it is easier to implement > encapsulated option rather than sub-option, as the implementer[s] do not > ... > Such encapsulation is not limited to one level. There is > > For this 3rd paragraph "sub-option" has returned. I really would like to > see this replaced by encapsulated and not to use sub-option as this is > encapsulation! > > Such encapsulation is not limited to one level. There is > at least one defined option that is encapsulated twice: Identity > Association for Prefix Delegation (IA_PD, defined in [RFC3633], > section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section > 10). Such delegated prefix may contain an excluded prefix range that > is represented by PD_EXCLUDE option that is conveyed as encapsulated > inside the IAPREFIX option (PD_EXCLUDE, defined in [RFC6603]). It > seems awkward > to refer to such an option as a doubly encapsulated > option, therefore "encapsulated option" term is typically used, > regardless of the nesting level. > > 11. Section 10: > > Can we replace "nodes" and "node" with "clients" and "client"? This > section starts out with "DHCP is a protocol designed for provisioning > nodes." ... This should be "DHCP is a protocol designed for provisioning > clients.". > > Also: > > generate [client]-specific information. Such [a] solution does not > introduce > any additional state for the server and therefore scales better. > > ... > > For renewing other parameters, please use [the] Information Refresh Time > Option (defined in [RFC4242]). Introducing additional timers make > deployment unnecessarily complex and [SHOULD] be avoided. > > One note here is that RFC 4242 states "It is only used in Reply messages > in response to Information-Request messages." - so a "Renew" messages > cannot use it (the text says "For renewing" which doesn't necessarily imply > a Renew message.). > > 12. Section 11: > > nonce. That means that [the] provisioning server is the only one that > can > initiate reconfiguration. Other servers do not know [the nonce] and > [therefore] cannot > trigger reconfiguration. Therefore the only reliable way for clients > to refresh their configuration is to wait until T1 [or Information > Refresh Time] expires. > > 13. Section 12: > > example of such [a] case is a home network with a connection to two > independent ISPs. > > 14. Section 14: > > DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through > its use of link-local addresses, it [avoids] many of the > > requirements. [C]ommon sense still applies here. It is better to > split distinct values into separate [octets] rather than propose > overly complex bit shifting operations to save [] several bits (or > > is recommended to clarify (with normative language) whether a given > DHCPv6 option may appear once or multiple times. [The default assumption > is only once.] > > 15. Section 15: > > Such [] text is discouraged as there are several issues with it. > First, it assumes that client implementation that supports a given > option will always want to use it. This is not true. The second and > more important reason is that such [] text essentially duplicates > > Either at the end of this section (or possibly section 14), do we want to > provide any guidance about whether the ordering of multiple instances of > any option can be assumed to have significance? I don't think RFC 3315 > clarified this and in many cases it doesn't matter (such as IA_NA/IA_PD > ordering). But, while we didn't do it and probably don't recommend doing > so, but the DNS Servers (addresses) option could have only allowed a single > address and we could have allowed multiple instances. In this case, order > would likely be significant. > > I think this goes back to saying - if order is important to you, do it in > your option(s) - have a list of items rather than a single item. > > And, we should simply say that the order of options, even multiple > instances of the same option, is NOT significant and MUST NOT be assumed. > > 16. Section 17: > > I'd move the requestor text from the first paragraph into the start of the > 2nd. The reason is that you start with three major entities, then add the > fourth, but the say "those three major components". So, I think the > following makes more sense: > > There are three major entities in DHCPv6 protocol: server, relay > agent, and client. It is very helpful for > [implementers] to include separate sections that describe operation for > those three major [entities]. Even when a given entity does not > participate, it is useful to have a very short section stating that > it must not send a given option and must ignore it when received. > > There is also a separate entity called requestor, which is a special > client-like type that participates in leasequery protocol [RFC5007] > and [RFC5460]. [A] similar section for [the] requestor is not required, > unless the new option has anything to do with requestor (or it is likely > that the reader may think that is has). It should be noted that while > in > [the] majority of > > Later, replace be with by: > > appear in certain message or being sent [by] certain entities. > > And: > > Typically new options are requested by clients and assigned by [the] > server, so there is no specific relay behavior. Nevertheless it is > good to include a section for relay agent [behavior] and simply state > > 17. Section 17.1 > > How about naming this section "Sample DHCPv6 Client Behavior Text"? > > And: > > Client[s] MAY request option foo, as defined in [RFC3315], sections > > And: > > Optional text (if the option contains FQDN): If the client request[s] an > option that conveys [an] FQDN, it is expected that [the] content[s] of > that option > will be resolved using DNS. Hence the following text may be useful: > Client that requests option foo SHOULD also request option > OPTION_DNS_SERVERS specified in [RFC3646]. > > Client[s] MUST discard option foo if it is invalid (i.e. did not pass > validation steps defined in Section X.Y). > > 18. Section 17.2 > > How about naming this section "Sample DHCPv6 Server Behavior Text"? > > Optional text: Server[s] MUST NOT send more than one instance of foo > option. > > Optional text (if server is never supposed to receive option foo): > Server[s] MUST ignore incoming foo option. > > 19. Section 18 > > Authors often ask themselves a question whether their proposal > updates exist RFCs, especially [[RFC3315]]. [In April 2013] > there were [about 80] options defined. > > (I think it best not to be that specific, as the count will continue to > change and the 'time of writing' may move.) > > changes something in already defined behavior, e.g. servers must > discard incoming messages if option foo is invalid or missing, then > the "updates" phrase is warranted. > > I don't think this is really a good example. I think it should be when > existing behavior (as documented in RFC 3315) is replaced by new behavior > (such as the stateful -issues draft does). Adding new options or messages > that may have different behavior still just extends. Only when text is > replaced or modified is updates appropriate. For example, RFC 6644 and > draft-ietf-dhc-dhcpv6-solmaxrt-update clearly updates RFC 3315 - they > replace existing with new text. Perhaps these are better examples? > > 20. Section 19: > > endpoints and men in the middle. Other authentication mechanisms may > ... > least to man-in-the-middle attacks from within the network, even > > Should be consistent and use "man-in-the-middle" in both places? (That's > at least what Wikipedia uses - > http://en.wikipedia.org/wiki/Man-in-the-middle_attack). > > And in the following replace supporting with support: > > without requiring symmetric key pairs or [support] from any key > > And in v6 we have no broadcast so best to replace broadcast with multicast > (may also want to drop 'local'?) > > security. An IP address field might be made to carry a loopback > address, or local [multicast] address, and depending on the protocol > > 21. Section 22: > > Usually 2119 and 3115 would be Normative References? But this is sometimes > a judgment call. > > 22. What might be missing? > > I wonder whether more might be said about Relay options and that they too > use the same number space as client/server options? Perhaps this is already > clear enough in RFC 3315. > > 23. Summary: > > A great job on this document and I'm glad it hopefully will be finished > soon! Thanks much Tomek for taking it over and working to get it this far. > Much of what I have commented on is minor and would be addressed by > RFC-Editor anyway (there is likely a lot more they will do too!). But, I do > have a few significant comments that I hope can be addressed in a -12 and > will not require another WGLC. > > I do hope that for those that have read this far that you also look over > the document as it is important work!! > Thanks to Tomek for pushing this forward, I have very little time of late for pursuits here. Provided the other authors agree on Bernie's edits, I'm also of the opinion we should move this document forward, although for form's sake we should maybe plan to do WGLC on -12. > > Regards, > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Bernie Volz (volz) > Sent: Tuesday, April 09, 2013 11:06 AM > To: dhcwg@ietf.org > Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by > April 24 > > Folks, the authors of draft-ietf-dhc-option-guidelines-11, > http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's > ready for a WGLC. There's been discussion and comment already, but more > eyes on and a "final" review of this work are required to advance it. > > This document is critical as it provides guidance to others in the IETF > that may not be DHCP "experts" when they need to write a DHCP option > internet-draft. > > At the time of this writing, there is no IPR reported against this draft. > > Please review the draft and indicate whether or not you feel it is ready > to be published. Your response matters to the process, so please do respond. > > As Tomek is an author, I will evaluate consensus after April 24, 2013. > > Thanks! > > - Bernie > > > _______________________________________________ > 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 > -- David W. Hankins SRE - Systems Engineer Google, Inc. :x --089e0122edb2d2c14f04db841e00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Apr 14, 2013 at 1:13 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
NOTE: WG co-chair hat OFF ... these are my c= omments as an individual "member" of the WG.

I fully support this work and would like to see it advance. And I have done= a somewhat careful review with the comments below.

1. I think the "updates RFC 3315" in the header and also in the A= bstract is wrong and should be removed. There is nothing in this document t= hat specifically changes anything in RFC 3315.


I think an earlier version of th= e draft had some text that proposed to clarify some point. =A0I suspect ins= tead I was absolved of my own misunderstanding on the point, but this wasn&= #39;t removed.
=A0
2. =A0In section 3 - add text in brackets:

=A0 =A0accessing the external Internet via local assist services that [the]=
=A0 =A0network must also provide (such as domain name servers, or routers).=

...

=A0 =A0this is one [of the] main reason[s] for the use of DHCPv6 in corpora= te
=A0 =A0enterprises.

3. In section 5 - replace/add text in brackets:

=A0 =A0This [means] that implementations will [likely] be able to reuse cod= e paths
=A0 =A0designed to support the other options.

Another choice would be "This assumes that implementations will be abl= e ...".

Drop the last sentence as it is not true: "It is only a list of option= format fragments which are used in two or more options."

4. Section 5.1:

For:
=A0 =A0o =A0DHCPv6 server unicast address [RFC3315]
You need to also add "(a single address only)".

5. Section 5.3:

=A0 =A0Sometimes there is a need to convey [a/an] IPv6 prefix. =A0The infor= mation to
=A0 =A0be carried by [such] an option includes the 128-bit IPv6 prefix toge= ther

Wonder whether the equation should be:
=A0 =A0 =A0 =A0 (<prefix6-len> + 7) /8
As written, it may be misevaluated as division has higher preference than a= ddition (usually). We could further clarify the integer portion is used, bu= t I think that is clear as you can't have 6.5 octets.

In the example, prefix-len should be prefix6-len:

=A0 =A0For example, the prefix 2001:db8::/60 would be encoded with an
=A0 =A0option-length of 9, prefix6-len would be set to 60, the ipv6-prefix<= br> =A0 =A0would be 8 octets and would contains octets 20 01 0d b8 00 00 00 00.=

And replace the last sentence paragraph with:

=A0 =A0It should be noted that the IAPREFIX option defined by [RFC3633]
=A0 =A0uses a constant length prefix. =A0The concern about option length wa= s
=A0 =A0not well understood at the time of its publication.

6. Section 5.7 - I wonder whether it is worth to remind future writers they= MUST document the allowed encoding for this data.

7. Section 5.8 - I wonder whether it is worth to point out that this really= is a specific encoding instances of section 5.7, and in this case the enco= de can also support multiple instances as the DNS wire encoded format allow= s on to determine the end of a FQDN (because of the 0 "." field).=

8. Section 6:

The following is a bit odd ...

=A0 Therefore the conditional formatting requires new code to
=A0 =A0be written, as well as introduces an implementation problem; as it =A0 =A0requires that all speakers implement all current and future
=A0 =A0conditional formats.

=A0 =A0Conditional formatting is not recommended, except in cases where the=
=A0 =A0DHCPv6 option has already been deployed experimentally, and all but<= br> =A0 =A0one conditional format is deprecated.

Can we replace this with:

=A0 Conditional formatting requires new code to be written and complicates<= br> =A0 future interoperability should new conditional formats be added; and =A0 existing code has to ignore conditional formats that it does not suppor= t.

Do we even want to suggest that "deployed experimentally" is usef= ul? It is an experiment so why would the 'official' IETF option use= it? I would just suggest not to go there - I don't want someone arguin= g 'well, I experimented in my network using option 55555 with this cond= itional format and this document lets me keep that conditional format."= ;

9. Section 8.

Reword:

=A0 =A0Section 7), so one of them must be chosen. =A0This section is intend= ed
=A0 =A0as a help to make an informed decision in that regard.

To:

=A0 =A0Section 7), so one of them must be chosen. =A0This section is intend= ed
=A0 =A0to help make an informed decision in that regard.

And also:

=A0 =A0FQDN imposes [a] number of additional failure modes and issues that<= br> =A0 =A0should be dealt with:

And I still have concerns about #4 and #7 in this list. They don't real= ly make that much sense as written.

Perhaps for 4 the intent was:

=A0 4. The client has to determine for which address families DNS is querie= d? A or AAAA records or both? And if both, which is preferred? Client imple= mentations are encouraged to follow [RFC 6555] if both address families are= possible.

For 7, I think this issue refers to encoding that is not DNS wire format - = as I don't understand what the issue is for IDNs for DNS wire encoding?= But this goes back to my issue with #6 for Section 5.7 that documenting th= e encoding is important.

I suspect this issue 7 goes back to when UTF-8 or ASCII was intended as a p= ossible 'string' encoding (as then addresses in string format could= be sent). The text in Section 8 never really discussed 'FQDN' enco= ding, but there really is the question as to what does "FQDN" mea= n? I don't think we generally mean it to be an ASCII representation of = a v4 or v6 address.

So perhaps this means that 'FQDN' is a bad term used in this sectio= n or that we need additional text to discuss this alternate form for a &quo= t;string" encoding of an ASCII representation for a v4/v6 address or a= FQDN. (The 2nd paragraph in this section 8 starts out with "On the sp= ecific subject of desiring to configure a value using a FQDN instead of a b= inary IP address" - yet Med's original proposal wasn't a choic= e between the two but an ENCODING that allowed an FQDN or "ascii"= address. So perhaps we have not really answered his quest for that? (Which= may be why he sent his response to this WGLC.)

Perhaps for 7 in the list, remove it and add a new paragraph to end of the = section (feel free to edit and extend):

Some may be tempted to use a "string" encoding which would allow = the string representation of an address or a domain name. However, this MUS= T be avoided as it has many potential security and implementation issues, s= ome of which are:
1. How is this data encoded? Especially consider International Domain Names= and non-ASCII characters in domain names.
2. How is this data validated? While it is easy to determine whether the st= ring representation of an IPv6 (or IPv4) address is specified, it is more d= ifficult to validate domain names as valid FQDNs. And, is a terminal "= dot" assumed for the domain name or are relative names allowed (if so,= this of course raises the question of the search list being used by the cl= ient).

10. Section 9:

=A0 =A0From the implementation perspective, it is easier to implement
=A0 =A0encapsulated option rather than sub-option, as the implementer[s] do= not
...
=A0 =A0Such encapsulation is not limited to one level. =A0There is

For this 3rd paragraph "sub-option" has returned. I really would = like to see this replaced by encapsulated and not to use sub-option as this= is encapsulation!

=A0 =A0Such encapsulation is not limited to one level. =A0There is
=A0 =A0at least one defined option that is encapsulated twice: Identity
=A0 =A0Association for Prefix Delegation (IA_PD, defined in [RFC3633],
=A0 =A0section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], sectio= n
=A0 =A010). =A0Such delegated prefix may contain an excluded prefix range t= hat
=A0 =A0is represented by PD_EXCLUDE option that is conveyed as encapsulated=
=A0 =A0inside the IAPREFIX option (PD_EXCLUDE, defined in [RFC6603]). =A0It= seems awkward
=A0 =A0to refer to such an option as a doubly encapsulated
=A0 =A0option, therefore "encapsulated option" term is typically = used,
=A0 =A0regardless of the nesting level.

11. Section 10:

Can we replace "nodes" and "node" with "clients&qu= ot; and "client"? This section starts out with "DHCP is a pr= otocol designed for provisioning nodes." ... This should be "DHCP= is a protocol designed for provisioning clients.".

Also:

=A0 =A0generate [client]-specific information. =A0Such [a] solution does no= t introduce
=A0 =A0any additional state for the server and therefore scales better.

...

=A0 =A0For renewing other parameters, please use [the] Information Refresh = Time
=A0 =A0Option (defined in [RFC4242]). =A0Introducing additional timers make=
=A0 =A0deployment unnecessarily complex and [SHOULD] be avoided.

One note here is that RFC 4242 states "It is only used in Reply messag= es in response to Information-Request messages." - so a "Renew&qu= ot; messages cannot use it (the text says "For renewing" which do= esn't necessarily imply a Renew message.).

12. Section 11:

=A0 =A0nonce. =A0That means that [the] provisioning server is the only one = that can
=A0 =A0initiate reconfiguration. =A0Other servers do not know [the nonce] a= nd [therefore] cannot
=A0 =A0trigger reconfiguration. =A0Therefore the only reliable way for clie= nts
=A0 =A0to refresh their configuration is to wait until T1 [or Information R= efresh Time] expires.

13. Section 12:

=A0 =A0example of such [a] case is a home network with a connection to two<= br> =A0 =A0independent ISPs.

14. Section 14:

=A0 =A0DHCPv6 [RFC3315] allows for packet sizes up to 64KB. =A0First, throu= gh
=A0 =A0its use of link-local addresses, it [avoids] many of the

=A0 =A0requirements. =A0[C]ommon sense still applies here. =A0It is better = to
=A0 =A0split distinct values into separate [octets] rather than propose
=A0 =A0overly complex bit shifting operations to save [] several bits (or
=A0 =A0is recommended to clarify (with normative language) whether a given<= br> =A0 =A0DHCPv6 option may appear once or multiple times. [The default assump= tion
=A0 =A0is only once.]

15. Section 15:

=A0 =A0Such [] text is discouraged as there are several issues with it.
=A0 =A0First, it assumes that client implementation that supports a given =A0 =A0option will always want to use it. =A0This is not true. =A0The secon= d and
=A0 =A0more important reason is that such [] text essentially duplicates
Either at the end of this section (or possibly section 14), do we want to p= rovide any guidance about whether the ordering of multiple instances of any= option can be assumed to have significance? I don't think RFC 3315 cla= rified this and in many cases it doesn't matter (such as IA_NA/IA_PD or= dering). But, while we didn't do it and probably don't recommend do= ing so, but the DNS Servers (addresses) option could have only allowed a si= ngle address and we could have allowed multiple instances. In this case, or= der would likely be significant.

I think this goes back to saying - if order is important to you, do it in y= our option(s) - have a list of items rather than a single item.

And, we should simply say that the order of options, even multiple instance= s of the same option, is NOT significant and MUST NOT be assumed.

16. Section 17:

I'd move the requestor text from the first paragraph into the start of = the 2nd. The reason is that you start with three major entities, then add t= he fourth, but the say "those three major components". So, I thin= k the following makes more sense:

=A0 =A0There are three major entities in DHCPv6 protocol: server, relay
=A0 =A0agent, and client. =A0 It is very helpful for
=A0 =A0[implementers] to include separate sections that describe operation = for
=A0 =A0those three major [entities]. =A0Even when a given entity does not =A0 =A0participate, it is useful to have a very short section stating that<= br> =A0 =A0it must not send a given option and must ignore it when received.
=A0 =A0There is also a separate entity called requestor, which is a special=
=A0 =A0client-like type that participates in leasequery protocol [RFC5007]<= br> =A0 =A0and [RFC5460]. [A] similar section for [the] requestor is not requir= ed,
=A0 =A0unless the new option has anything to do with requestor (or it is li= kely
=A0 =A0that the reader may think that is has). =A0It should be noted that w= hile in
=A0 =A0[the] majority of

Later, replace be with by:

=A0 =A0appear in certain message or being sent [by] certain entities.

And:

=A0 =A0Typically new options are requested by clients and assigned by [the]=
=A0 =A0server, so there is no specific relay behavior. =A0Nevertheless it i= s
=A0 =A0good to include a section for relay agent [behavior] and simply stat= e

17. Section 17.1

How about naming this section "Sample DHCPv6 Client Behavior Text"= ;?

And:

=A0 =A0Client[s] MAY request option foo, as defined in [RFC3315], sections<= br>
And:

=A0 =A0Optional text (if the option contains FQDN): If the client request[s= ] an
=A0 =A0option that conveys [an] FQDN, it is expected that [the] content[s] = of that option
=A0 =A0will be resolved using DNS. =A0Hence the following text may be usefu= l:
=A0 =A0Client that requests option foo SHOULD also request option
=A0 =A0OPTION_DNS_SERVERS specified in [RFC3646].

=A0 =A0Client[s] MUST discard option foo if it is invalid (i.e. =A0did not = pass
=A0 =A0validation steps defined in Section X.Y).

18. Section 17.2

How about naming this section "Sample DHCPv6 Server Behavior Text"= ;?

=A0 =A0Optional text: Server[s] MUST NOT send more than one instance of foo=
=A0 =A0option.

=A0 =A0Optional text (if server is never supposed to receive option foo): =A0 =A0Server[s] MUST ignore incoming foo option.

19. Section 18

=A0 =A0Authors often ask themselves a question whether their proposal
=A0 =A0updates exist RFCs, especially [[RFC3315]]. =A0[In April 2013]
=A0 =A0there were [about 80] options defined.

(I think it best not to be that specific, as the count will continue to cha= nge and the 'time of writing' may move.)

=A0 =A0changes something in already defined behavior, e.g. =A0servers must<= br> =A0 =A0discard incoming messages if option foo is invalid or missing, then<= br> =A0 =A0the "updates" phrase is warranted.

I don't think this is really a good example. I think it should be when = existing behavior (as documented in RFC 3315) is replaced by new behavior (= such as the stateful -issues draft does). Adding new options or messages th= at may have different behavior still just extends. Only when text is replac= ed or modified is updates appropriate. For example, RFC 6644 and draft-ietf= -dhc-dhcpv6-solmaxrt-update clearly updates RFC 3315 - they replace existin= g with new text. Perhaps these are better examples?

20. Section 19:

=A0 =A0endpoints and men in the middle. =A0Other authentication mechanisms = may
...
=A0 =A0least to man-in-the-middle attacks from within the network, even

Should be consistent and use "man-in-the-middle" in both places? = (That's at least what Wikipedia uses - http://en.wikipedia.org= /wiki/Man-in-the-middle_attack).

And in the following replace supporting with support:

=A0 =A0without requiring symmetric key pairs or [support] from any key

And in v6 we have no broadcast so best to replace broadcast with multicast = (may also want to drop 'local'?)

=A0 =A0security. =A0An IP address field might be made to carry a loopback =A0 =A0address, or local [multicast] address, and depending on the protocol=

21. Section 22:

Usually 2119 and 3115 would be Normative References? But this is sometimes = a judgment call.

22. What might be missing?

I wonder whether more might be said about Relay options and that they too u= se the same number space as client/server options? Perhaps this is already = clear enough in RFC 3315.

23. Summary:

A great job on this document and I'm glad it hopefully will be finished= soon! Thanks much Tomek for taking it over and working to get it this far.= Much of what I have commented on is minor and would be addressed by RFC-Ed= itor anyway (there is likely a lot more they will do too!). But, I do have = a few significant comments that I hope can be addressed in a -12 and will n= ot require another WGLC.

I do hope that for those that have read this far that you also look over th= e document as it is important work!!

Thanks to Tomek for pushing this forward, I have very li= ttle time of late for pursuits here. =A0Provided the other authors agree on= Bernie's edits, I'm also of the opinion we should move this docume= nt forward, although for form's sake we should maybe plan to do WGLC on= -12.
=A0

Regards,

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, April 09, 2013 11:06 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by Ap= ril 24

Folks, the authors of draft-ietf-dhc-option-guidelines-11,
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelin= es-11, feel it's ready for a WGLC. =A0There's been discussion a= nd comment already, but more eyes on and a "final" review of this= work are required to advance it.

This document is critical as it provides guidance to others in the IETF tha= t may not be DHCP "experts" when they need to write a DHCP option= internet-draft.

At the time of this writing, there is no IPR reported against this draft.
Please review the draft and indicate whether or not you feel it is ready to= be published. Your response matters to the process, so please do respond.<= br>
As Tomek is an author, I will evaluate consensus after April 24, 2013.

Thanks!

- =A0 =A0 =A0 Bernie


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



--
=
David W. Hankins
SRE - Systems Engineer
Google, Inc.
:x
--089e0122edb2d2c14f04db841e00-- From wwwrun@rfc-editor.org Mon Apr 29 11:50:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D2821F9B03; Mon, 29 Apr 2013 11:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[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 NbSub54jE3ZI; Mon, 29 Apr 2013 11:50:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A2B2D21F9A68; Mon, 29 Apr 2013 11:50:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0BC74B1E008; Mon, 29 Apr 2013 11:50:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429185014.0BC74B1E008@rfc-editor.org> Date: Mon, 29 Apr 2013 11:50:14 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6925 on The DHCPv4 Relay Agent Identifier Sub-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: Mon, 29 Apr 2013 18:50:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6925 Title: The DHCPv4 Relay Agent Identifier Sub-Option Author: B. Joshi, R. Desetti, M. Stapp Status: Standards Track Stream: IETF Date: April 2013 Mailbox: bharat_joshi@infosys.com, ramakrishnadtv@infosys.com, mjs@cisco.com Pages: 8 Characters: 17664 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-relay-id-suboption-13.txt URL: http://www.rfc-editor.org/rfc/rfc6925.txt This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/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 wwwrun@rfc-editor.org Mon Apr 29 11:51:14 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68E021F8480; Mon, 29 Apr 2013 11:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[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 ZC0K04-rOK5s; Mon, 29 Apr 2013 11:51:13 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AE2C121F9B1A; Mon, 29 Apr 2013 11:51:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31780B1E010; Mon, 29 Apr 2013 11:50:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429185036.31780B1E010@rfc-editor.org> Date: Mon, 29 Apr 2013 11:50:36 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6926 on DHCPv4 Bulk Leasequery X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 18:51:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6926 Title: DHCPv4 Bulk Leasequery Author: K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz Status: Standards Track Stream: IETF Date: April 2013 Mailbox: kkinnear@cisco.com, mjs@cisco.com, ramakrishnadtv@infosys.com, bharat_joshi@infosys.com, neil.e.russell@gmail.com, kurapati@juniper.net, volz@cisco.com Pages: 41 Characters: 88215 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt URL: http://www.rfc-editor.org/rfc/rfc6926.txt The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/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 volz@cisco.com Mon Apr 29 13:41:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AAF21F9A50 for ; Mon, 29 Apr 2013 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 92bIQyv+vF3M for ; Mon, 29 Apr 2013 13:41:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 188F121F9B56 for ; Mon, 29 Apr 2013 13:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7847; q=dns/txt; s=iport; t=1367268075; x=1368477675; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EDW4jw15yUJ5RIHjpaxKN1XmSXqpp67ZAM67f7cQc7I=; b=c2rHyEFW9rV74T46ErvuR4ZNIV8HIkkEmimsMrCF3Q6p8DH2BLm356b+ QD5RqkoxhvMYhjOQD+4/ArOTReQPI1qXoqAClpD4d18yW3z8MAxRkx5z/ G5i/mkaDY822CwLVJn7ga3t/Qc7WtCrfHGjC+bIm46ZKmK8gFFzy4oveC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAILaflGtJV2c/2dsb2JhbABSgkNENr5NgQcWdIIgAQEELUwQAgEIDhQkMiUBAQQODYgOvguOaTEHgm5hA6hIgxGCKA X-IronPort-AV: E=Sophos;i="4.87,575,1363132800"; d="scan'208,217";a="204472367" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 29 Apr 2013 20:41:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3TKfATD022502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 20:41:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 15:41:11 -0500 From: "Bernie Volz (volz)" To: David Hankins Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: Ac45PhADpiAsKiu0RbSUFR9Qrk6K2gL8+I4AAAYpz4A= Date: Mon, 29 Apr 2013 20:41:10 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1851FD23@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E18504BC7@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.178] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1851FD23xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:41:20 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1851FD23xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks David for reviewing and support it! Good to hear from you! Just to make sure it wasn't missed (as it is near the end), you support thi= s: Thanks to Tomek for pushing this forward, I have very little time of late f= or pursuits here. Provided the other authors agree on Bernie's edits, I'm = also of the opinion we should move this document forward, although for form= 's sake we should maybe plan to do WGLC on -12. I will discuss with Tomek as to whether another WGLC will be needed; if so = it may be a short one just to confirm that everyone is happy with all of th= e edits. - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1851FD23xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks David for reviewin= g and support it! Good to hear from you!

 <= /p>

Just to make sure it wasn= ’t missed (as it is near the end), you support this:

 <= /p>

Thanks to Tomek for pushing this forward, I have ver= y little time of late for pursuits here.  Provided the other authors a= gree on Bernie's edits, I'm also of the opinion we should move this documen= t forward, although for form's sake we should maybe plan to do WGLC on -12.

 <= /p>

I will discuss with Tomek= as to whether another WGLC will be needed; if so it may be a short one jus= t to confirm that everyone is happy with all of the edits.

 <= /p>

- =          Bernie=

 

--_000_489D13FBFA9B3E41812EA89F188F018E1851FD23xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Mon Apr 29 19:58:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3221F9B2F for ; Mon, 29 Apr 2013 19:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6ZK-K7-dNpD for ; Mon, 29 Apr 2013 19:58:10 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3125721F9C09 for ; Mon, 29 Apr 2013 19:58:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUX8zQWOJrVXeGFcdWcuY02ws32a9oBOG@postini.com; Mon, 29 Apr 2013 19:58: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 8E1351B8115 for ; Mon, 29 Apr 2013 19:58:09 -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 85726190061; Mon, 29 Apr 2013 19:58:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 19:58:09 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHONTP8ALzX8DBH4k2eVgyK2ehtcZjuqAWA Date: Tue, 30 Apr 2013 02:58:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775167F3C@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <00DBEC10AD741242B8F5B0933F45A2E0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 02:58:17 -0000 I support this document, and would like to see it advance quickly, but I al= so have some suggestions for it. Most of these suggestions are made with = my AD hat off; however the suggestions for changes to section 13 are specif= ically with my AD hat on, because I think this stuff needs to be said, and = I wouldn't have known to say it before I started thinking about chartering = from the perspective of an AD. But even with my AD hat on, I'm not saying you have to add that text=97just= that as your AD, I think it would be beneficial to the working group in th= e long run. Obviously, that text is substantial enough to require a new W= GLC. First, I've suggested before that the document ought to be BCP rather than = standards track. I suspect that it's been kept at Standards Track because= it updates RFC 3315, but Dave Hankins says it doesn't. The reason to cal= l it a BCP is because it's something we can point to when people are writin= g DHCP extensions, whether they be trivial extensions or more serious ones.= I don't think you can call it Standards Track because there's nothing to= implement, and no way to evaluate interoperability. But we want it to be = a BCP so that it's a consensus document, which carries more weight than an = Informational document. In section 2, I would suggest adding a fourth bullet item: o If the option would work well in the particular deployment environment the proponents currently envision, but has equally valid uses in some other environment where the proposed option format would fail or produce inconsistent results. At the end of section 3, this text is a bit unclear: Note that the client still reserves the right to ignore values received via DHCPv6 Might be better to say: Note that the client is not required to configure any of these values via DHCPv6 Section 4: The primary guiding principle to follow in order to enhance an option's adoptability is simplification. More specifically, the option should be created in such a way that does not require any new or special case software to support. If old software currently deployed and in the field can adopt the option through supplied configuration facilities then it's fairly certain that new software can easily formally adopt it. how about: The primary guiding principle to follow in order to enhance an option's adoptability is reuse. The option should be created in such a way that does not require any new or special case software to support. If old software currently deployed and in the field can adopt the option through supplied configuration facilities then it's fairly certain that new software can easily formally adopt it. Here, why "bulk"? There are at least two classes of DHCPv6 options: A bulk class of options which are provided explicitly to carry data from one side of the DHCPv6 exchange to the other (such as nameservers, domain names, or time servers), and a protocol class of options How about: There are at least two classes of DHCPv6 options: simple options which are provided explicitly to carry data from one side of the DHCPv6 exchange to the other (such as nameservers, domain names, or time servers), and a protocol class of options Section 5 introduces the term "fragment" to mean a data field within an opt= ion. This term is never clearly defined. I think it means "data field o= f a particular type," but think about how someone who isn't a DHC working g= roup regular is going to read this text. I think the text needs to be rea= lly clear and formal about what is being described here=97this is a key par= t of the document. I don't think this is a major change, but it feels lik= e a lack to me at the moment. Another problem with this term is that it's used in the introduction to sec= tion 5, and then not again until section 13. In section 14, we see the te= rm used in its more usual sense=97talking about IP packet fragmentation. = It might be better to use a different word, like "data element" or somethin= g. 5.3, the equation is problematic: expressed using the following equation: >prefix6-len<+7/8 How about: expressed using the following equation: (prefix6_len + 7) / 8 I recommend against using angle brackets to delimit the variable name becau= se they look like comparison operators. I think it's better to just use a= n underscore and make it C-code: people will know what you mean. Alternat= ively, I would enthusiastically support using LISP code: expressed using the following equation: (/ (+ prefix6-len 7) 8) But I'm guessing you'll prefer the first suggestion... :) RFC 6603 uses the format you guys are recommending; might be a better refer= ence than the as-yet-unpublished MAP document. 5.7: I think you should call URLs out as a separate data type. Yes, they = are represented as a hunk of variable-length data, but the semantics are di= fferent, and this is important in UIs. Also, use "URI," not "URL." URIs= are ASCII text, not UTF8, and are defined in RFC 3986. Section 5 doesn't seem to define text strings. This is an important data = type, and it's not the same as raw data. It appears differently in the UI= , and it has encoding implications. You need to add a section that define= s this fragment format. It should talk about the problem of canonical and= non-canonical representations. It should also say that strings have no s= emantics; they are simply strings. If a data format has semantics other t= han just being text, it is not a string. E.g., an option carrying a presen= tation-format FQDN is not a string, and an option containing a URI is also = not a string, because they have different semantics. You should also point out that bit fields should be composed using 8-, 16- = or 32-bit numbers, and that bit fields can't cross those boundaries. I th= ink there are some examples of bit fields in options either existing or com= ing down the pike. 8: You should mention that the use of FQDN options is discouraged for optio= ns intended to configure hosts, because hosts may have multiple provisionin= g domains, and may get a different answer from the DNS depending on the pro= visioning domain. This is particularly a problem when the normal expected= use of the option makes sense with private DNS zone, as might be the case = with a corporate VPN. You touch on this in point 6, but I think it's a re= ally key point, and should be emphasized more heavily. This is something that only occurred to me a couple of days ago, although i= t obviously occurred to the authors earlier, but I think it's actually a re= ally good reason _not_ to use FQDNs in DHCP options unless the use case for= the DHCP option is really constrained=97for example, the recipient of the = option is expected to always be a HG, and never a host. Section 9: I have a bit of a quibble with using the term encapsulated here.= I tend to think of encapsulation as what relay agents to do DHCP message= s. I actually think that the term "nested" is better, even though RFC3315= doesn't use it. I leave it to the authors to decide what to do, but my p= ersonal advice would be to change to using "nested" rather than "encapsulat= ed." Also, I would change this: Those options are sometimes called sub-options, but this term is not precise and thus discouraged. to this: Those options are sometimes called sub-options, but this term actually means something else, and therefore should never be used to describe nested options. You should specifically say that RFC5908 never got proper review from the D= HC working group and contains many errors, and should not under any circums= tances be used as a template for future DHCP option definitions. You also use the term "sub-options" several times when I think you mean nes= ted options. Probably somebody else already caught this, but I mention it= just in case. :) Section 10 isn't very clear. It's not the case that stateful options (if = that is what you are referring to) place additional load on the server. R= ather it is that they require new extensions, new implementation complexity= , and additional database state on the server. In section 11 you might additionally want to mention that even when DHCP cl= ients refresh their configuration information, not all consumers of DHCP-so= urced configuration data notice these changes. For instance, if a server = is started using parameters received in an early DHCP transaction, but does= not check for updates from DHCP, it may well continue to use the same para= meter indefinitely. Modern notification systems take care of reconfigurin= g services when the client moves to a new network, but it's worth bearing i= n mind that a renew may not actually result in the client taking up new con= figuration information that it receives. In section 12, you should refer back to the bit about multiple provisioning= domains with respect to the FQDN option. It might be worth considering i= f there are other options that have the same problem. In section 13, you seem to be muddling formats and fragments. I propose t= he following replacement text: When defining a new option, it is best to synthesize the option format usin= g fragment types already in use. However, in some cases there may be no f= ragment type that accomplishes the intended purpose. Adding a simple DHCP option is straightforward, and generally something tha= t any working group can do, perhaps with some help from designated DHCP exp= erts. However, when new fragment types need to be devised, this requires = the attention of DHCP experts, and should not be done in a working group th= at doesn't have a quorum of such experts. This is true whether the new fr= agment type has the same structure as an existing fragment type, but has di= fferent semantics. It is equally true when the new format has a new struc= ture. Responsible Area Directors for working groups that wish to add a work item = to a working group charter to define a new DHCP option should get clarity f= rom the working group as to whether the new option is a simple DHCP option = with no new fragment type or new fragment semantics, or whether it in fact = will require new fragment types. A working group charter item should expl= icitly state which of these two types is required; if it is not known at th= e time of chartering, the charter should state that the working group will = study the question and recharter or seek help elsewhere if a new fragment t= ype is to be defined. If a working group needs a new fragment type, it is preferable to seek out = a working group whose members already have sufficient expertise to evaluate= the new work and try to come up with a new format that generalizes well an= d can be reused, rather than a single-use fragment type. If such a workin= g group is available, the work should be chartered in that working group as= a separate draft that documents the new fragment type. The working group= that needs the new fragment type can then define their new option referenc= ing the new fragment type document. This work can generally be done in pa= rallel so as not to delay the process significantly. In the event that there is no working group with DHCP expertise that can de= fine the new fragment type, the responsible AD should seek out help from kn= own DHCP experts within the IETF to provide advice and frequent early revie= w as the working group defines the new fragment type. The new fragment ty= pe should still be done in a separate document, even if it's done in the sa= me working group, so as to foster reuse of the new fragment type. The res= ponsible AD should work with the working group chairs and designated DHCP e= xperts to ensure that new fragment type document has in fact been carefully= reviewed by the experts and appears satisfactory. Responsible area directors for working groups that are considering defining= options that actually update the DHCP protocol, as opposed to simple optio= ns, should go through a process similar to that described above when trying= to determine where to do the work. Under no circumstances should a worki= ng group be given a charter deliverable to define a new DHCP option, and th= en on the basis of that charter item actually make updates to the DHCP prot= ocol. [this is left over from section 13, and doesn't relate to the text as I've = rewritten it, but is still important and maybe should be folded in somewher= e else, or maybe you should just title the above section "chartering requir= ements and advice for responsible ADs" and leave the following under the ex= isting head for section 13: When defining new options, one specific consideration to evaluate is whethe= r or not options of a similar format would need to have multiple or single = values encoded (whatever differs from the current option), and how that mig= ht be accomplished in a similar format. The matter of size considerations is further discussed in Section 14.] In the Option Size section, you should point out that relay agents have to = do fragment reassembly and refragment on transmission=97the relay can't sim= ply relay the fragments. So while fragmentation is allowed, if a new opti= on requires significant fragmentation, it probably isn't a good choice for = DHCP configuration; instead DHCP should simply point to a URI where the con= figuration information can be obtained. In section 15, creators of DHCP options are not protocol implementations, a= nd hence not appropriate targets for normative languages. Also, options i= n encapsulations are not ordered any more than top-level options are, so th= at doesn't work. If order is important, the things being ordered should b= e fields in an option, not separate options. You might also want to point= out that options values are never aligned within the DHCP packet: even the= option code and option length may appear on odd byte boundaries. In section 16, you should get rid of the "disappointing pace" language. T= hat's inappropriate. Section 16 also recapitulates draft-rajtar-dhc-v4con= figuration, I think. It might be worth referencing the document; I realiz= e that this will probably delay publication, but it'll give you an incentiv= e to get that document finished quickly as well. In 17.3, WTF: Optional text: Server MUST NOT send more than one instance of foo option. This is totally wrong. Documents that define new simple options can't pla= ce _any_ special requirements on servers. A document with language like t= he above is a DHCP protocol extension, not a simple option document. In 17.3, you should say "in the relay-forward message." You can't put any= normative text here either, but this bit is worth saying. It's never app= ropriate for a relay agent to add options to a message heading toward the c= lient, of course, and relay agents don't actually make relay-reply messages= anyway. In section 19, I would say "it is necessary to assume" rather than "it is p= rudent to assume." And "actual production use of the software may be vuln= erable..." I think the second point is debatable, but I prefer "you shoul= d be aware of this possibility" over "there is a 35% possibility that", and= "will probably be vulnerable" sounds like the latter. Suggest changing this: So it behooves an option's definition to contain any validation measures as can reasonably be made. To this: Authors of drafts defining new DHCP options are therefore strongly advised to explicitly define validation measures that recipients of such options are required to do before processing such options. However, validation measures are already required by RFC3315 or other specifications referenced by the new option document are redundant, and can introduce errors, so authors are equally strongly advised to refer to the base specification for any such validation language rather than copying it into the new specification. From Ted.Lemon@nominum.com Mon Apr 29 20:01:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0E21F8443 for ; Mon, 29 Apr 2013 20:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHzcnfvhEd4j for ; Mon, 29 Apr 2013 20:01:13 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6221F9AA5 for ; Mon, 29 Apr 2013 20:01:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUX8z+YT78Grg28ZQd39g5tNHYqnt/BZe@postini.com; Mon, 29 Apr 2013 20:01: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 184581B8115 for ; Mon, 29 Apr 2013 20:01:13 -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 0E39F190061; Mon, 29 Apr 2013 20:01:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 20:01:12 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 Thread-Index: AQHORU74jKTwdZvmiEaGzP8cB7ipWQ== Date: Tue, 30 Apr 2013 03:01:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775167F69@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E184EDAEC@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630775167F3C@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775167F3C@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 03:01:20 -0000 On Apr 29, 2013, at 10:58 PM, Ted Lemon wrote: > processing such options. However, validation measures > are already required by RFC3315 or other specifications Validation measures THAT are already defined=97sorry for the confusing omis= sion. From linux@thehobsons.co.uk Tue Apr 30 03:57:02 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1721F944A for ; Tue, 30 Apr 2013 03:57:02 -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 lrlM4xiCK5hq for ; Tue, 30 Apr 2013 03:57:02 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 8A91D21F8AF8 for ; Tue, 30 Apr 2013 03:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 8219A10401B for ; Tue, 30 Apr 2013 11:56:58 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W23M-OvPOGlv for ; Tue, 30 Apr 2013 11:56:58 +0100 (BST) Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 0B39D10401A for ; Tue, 30 Apr 2013 11:56:57 +0100 (BST) From: "Simon Hobson" To: dhcwg@ietf.org Date: Tue, 30 Apr 2013 11:56:59 +0100 X-Priority: 3 X-Mailer: MailForge 3.0 Mac OS X Message-ID: <0D6E16088A9D7EBF474768B814221EB3E@thehobsons.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] RFC 6925 on The DHCPv4 Relay Agent Identifier Sub-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: Tue, 30 Apr 2013 10:57:02 -0000 >This document defines a new Relay Agent Identifier sub-option for the >Dynamic Host Configuration Protocol (DHCP) Relay Agent Information >option. The sub-option carries a value that uniquely identifies the >relay agent device within the administrative domain. I'm not clear what problem this is trying to solve, and how it's going to do it. In the case of the factory floor network, I can't see what this identifier provides that's not already provided by the GI-Addr field. In the general case knowing the relay agent identifier won't narrow down the location of the client any further than GI-Addr. In the case where the relay agent serves multiple remote networks, it would appear that the agent identifier will be less specific than the GI-Addr. If the clients are connected to a switch, and so multiple clients can be served by one interface, then only the switch would know the locations - and could insert Option-82 into client requests. The relay agent will not know the location (switch port) unless the switch informs it by (eg) inserting something like Option-82. Or have I missed something ?