From Internet-Drafts@ietf.org Fri Jun 3 09:45:09 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C262E078C; Fri, 3 Jun 2011 09:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6O0M-Qj-JZA; Fri, 3 Jun 2011 09:45:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC52E0789; Fri, 3 Jun 2011 09:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603164509.11446.45499.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2011 09:45:09 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:45:09 -0000 --NextPart 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 : Subnet Allocation Option Author(s) : R. Johnson, et al Filename : draft-ietf-dhc-subnet-alloc-12.txt Pages : 30 Date : 2011-06-03 This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-subnet-alloc-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-03093308.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Sat Jun 4 10:04:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1EE06C3; Sat, 4 Jun 2011 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmjfHpDymIFO; Sat, 4 Jun 2011 10:04:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F5AE06A6; Sat, 4 Jun 2011 10:04:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> Date: Sat, 04 Jun 2011 10:04:24 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 17:04:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : The DHCPv4 Relay Agent Identifier Suboption Author(s) : Bharat Joshi Mark Stapp Filename : draft-ietf-dhc-relay-id-suboption-08.txt Pages : 8 Date : 2011-06-04 This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is typically administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt From bharat_joshi@infosys.com Sun Jun 5 02:06:04 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ECF21F844D for ; Sun, 5 Jun 2011 02:06:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h40k0QJ+lbSP for ; Sun, 5 Jun 2011 02:06:03 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id EF0BF21F844B for ; Sun, 5 Jun 2011 02:06:02 -0700 (PDT) X-TM-IMSS-Message-ID: <43573d5c0006ee5b@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 43573d5c0006ee5b ; Sun, 5 Jun 2011 14:37:22 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Sun, 5 Jun 2011 14:36:00 +0530 From: Bharat Joshi To: "dhcwg@ietf.org" Date: Sun, 5 Jun 2011 14:33:27 +0530 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwi2YMzGEKrsYkCTqOR+0a/a2b14QAheuTk Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> In-Reply-To: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 09:06:04 -0000 Hi=20All, =20=20=20=20=20=20This=20draft=20was=20under=20IESG=20review=20and=20a=20= new=20revision=20was=20required=20as=20it=20had=20three=20DISCUSS=20point= s.=20Mark=20was=20not=20getting=20enough=20time=20to=20push=20this=20work= .=20We=20needed=20this=20draft=20for=20Bulk=20Lease=20Query=20work=20and= =20so=20we=20decided=20to=20help. =20=20=20=20=20=20=20Apart=20from=20the=20three=20DISCUSS=20position,=20t= here=20was=20a=20comment=20from=20Ted.=20Ted=20had=20suggested=20that=20t= he=20usage=20of=20DUID=20as=20relay-id=20as=20defined=20in=20this=20draft= =20is=20not=20correct.=20DUID=20is=20typically=20tied=20down=20to=20the= =20device=20and=20the=20use=20cases=20in=20this=20draft=20required=20same= =20relay-id=20to=20be=20used=20if=20a=20relay-agent=20is=20replaced. =20=20=20=20=20=20=20=20In=20this=20revision,=20we=20have=20addressed=20a= ll=20the=20DISCUSS=20positions.=20We=20have=20also=20removed=20both=20the= =20relay-id=20type=20ASCII=20and=20DUID.=20We=20have=20introduced=20a=20n= ew=20relay-id=20type=20OPAQUE.=20This=20new=20relay-id=20type=20can=20be= =20administratively=20configured=20and=20is=20a=20series=20of=20octets. =20=20=20=20=20=20=20=20Now,=20as=20the=20above=20changes=20are=20more=20= than=20minor=20changes,=20I=20think=20that=20it=20will=20first=20have=20t= o=20go=20through=20working-group.=20So=20I=20request=20people=20to=20revi= ew=20this=20draft=20(=20only=205=20pages=20)=20and=20post=20their=20comme= nts. Regards, Bharat ________________________________________ From:=20dhcwg-bounces@ietf.org=20[dhcwg-bounces@ietf.org]=20On=20Behalf= =20Of=20internet-drafts@ietf.org=20[internet-drafts@ietf.org] Sent:=20Saturday,=20June=2004,=202011=2010:34=20PM To:=20i-d-announce@ietf.org Cc:=20dhcwg@ietf.org Subject:=20[dhcwg]=20I-D=20Action:=20draft-ietf-dhc-relay-id-suboption-08= .txt A=20New=20Internet-Draft=20is=20available=20from=20the=20on-line=20Intern= et-Drafts=20directories.=20This=20draft=20is=20a=20work=20item=20of=20the= =20Dynamic=20Host=20Configuration=20Working=20Group=20of=20the=20IETF. =20=20=20=20=20=20=20=20Title=20=20=20=20=20=20=20=20=20=20=20:=20The=20D= HCPv4=20Relay=20Agent=20Identifier=20Suboption =20=20=20=20=20=20=20=20Author(s)=20=20=20=20=20=20=20:=20Bharat=20Joshi =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20Mark=20Stapp =20=20=20=20=20=20=20=20Filename=20=20=20=20=20=20=20=20:=20draft-ietf-dh= c-relay-id-suboption-08.txt =20=20=20=20=20=20=20=20Pages=20=20=20=20=20=20=20=20=20=20=20:=208 =20=20=20=20=20=20=20=20Date=20=20=20=20=20=20=20=20=20=20=20=20:=202011-= 06-04 =20=20=20This=20draft=20defines=20a=20new=20Relay=20Agent=20Identifier=20= suboption=20for=20the =20=20=20Dynamic=20Host=20Configuration=20Protocol's=20(DHCP)=20Relay= =20Agent=20Information =20=20=20option.=20=20The=20suboption=20carries=20a=20value=20that=20uniq= uely=20identifies=20the =20=20=20relay=20agent=20device=20within=20the=20administrative=20domain.= =20=20The=20value=20is =20=20=20typically=20administratively-configured=20in=20the=20relay=20age= nt.=20=20The =20=20=20suboption=20allows=20a=20DHCP=20relay=20agent=20to=20include=20t= he=20identifier=20in=20the =20=20=20DHCP=20messages=20it=20sends. A=20URL=20for=20this=20Internet-Draft=20is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.= txt Internet-Drafts=20are=20also=20available=20by=20anonymous=20FTP=20at: ftp://ftp.ietf.org/internet-drafts/ This=20Internet-Draft=20can=20be=20retrieved=20at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.t= xt _______________________________________________ dhcwg=20mailing=20list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From pavan.kurapati@gmail.com Sun Jun 5 08:01:50 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429001F0C34 for ; Sun, 5 Jun 2011 08:01:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfKQqgYSnVEa for ; Sun, 5 Jun 2011 08:01:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3265B21F850D for ; Sun, 5 Jun 2011 08:01:49 -0700 (PDT) Received: by vxg33 with SMTP id 33so2920747vxg.31 for ; Sun, 05 Jun 2011 08:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=by3PnjQNe4J0yQXklNUFALBTie1KGEur9Je59srdGf4=; b=JGaZljbpSheKev/Y4U4Eilzh6ZIPZxpRtvwjQzd+NIW7i+7Zst3rrhPwsKb2racTJD vCoRAC2bmzIAIkGFQ8B6rXC/KzSrAlwaAyhHwbR2IoqKC700ZKW0hmNJ55lcTyg5qdsE A2/fAbmNPk5AaQ6It3FzRvFBuYxhaX088dwSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DU4N6Vy5gi1DBYu20s33u89WqNERSRluL79pKddkMIxLvYf4SBAZnZOdCdCix+H0DF Z9aPtoHVl40zmXSzHCN7UbWHlICfC2iN+JwGGlJCwkiuJ/jzQAfaerK7zmVkolNGruGU blOIz758ox3XsjZB0c1zDNEzD6IVo3pbMvLwM= MIME-Version: 1.0 Received: by 10.52.187.193 with SMTP id fu1mr5584889vdc.49.1307286106862; Sun, 05 Jun 2011 08:01:46 -0700 (PDT) Received: by 10.52.112.71 with HTTP; Sun, 5 Jun 2011 08:01:46 -0700 (PDT) In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com> Date: Sun, 5 Jun 2011 20:31:46 +0530 Message-ID: From: Pavan Kurapati To: Bharat Joshi Content-Type: multipart/alternative; boundary=bcaec548a11904f5d804a4f8445e Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 15:01:50 -0000 --bcaec548a11904f5d804a4f8445e Content-Type: text/plain; charset=ISO-8859-1 Bharat, Draft looks good. Just one minor editorial comment and one clarification needed below. > "DHCP typically identifies clients based on information in their DHCP messages" You might want to replace the first "DHCP" with DHCP server. If you do not want to restrict to server here you may say network entity I assume the inclusion of "type" field now is for any future consideration of including other types like DUID? Else it seems redundant, now that we have only 1 type in the sub-option. Thanks, Pavan On Sun, Jun 5, 2011 at 2:33 PM, Bharat Joshi wrote: > Hi All, > > This draft was under IESG review and a new revision was required as it > had three DISCUSS points. Mark was not getting enough time to push this > work. We needed this draft for Bulk Lease Query work and so we decided to > help. > > Apart from the three DISCUSS position, there was a comment from Ted. > Ted had suggested that the usage of DUID as relay-id as defined in this > draft is not correct. DUID is typically tied down to the device and the use > cases in this draft required same relay-id to be used if a relay-agent is > replaced. > > In this revision, we have addressed all the DISCUSS positions. We > have also removed both the relay-id type ASCII and DUID. We have introduced > a new relay-id type OPAQUE. This new relay-id type can be administratively > configured and is a series of octets. > > Now, as the above changes are more than minor changes, I think that > it will first have to go through working-group. So I request people to > review this draft ( only 5 pages ) and post their comments. > > Regards, > Bharat > ________________________________________ > From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Saturday, June 04, 2011 10:34 PM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.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 : The DHCPv4 Relay Agent Identifier Suboption > Author(s) : Bharat Joshi > Mark Stapp > Filename : draft-ietf-dhc-relay-id-suboption-08.txt > Pages : 8 > Date : 2011-06-04 > > This draft defines a new Relay Agent Identifier suboption for the > Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information > option. The suboption carries a value that uniquely identifies the > relay agent device within the administrative domain. The value is > typically administratively-configured in the relay agent. The > suboption allows a DHCP relay agent to include the identifier in the > DHCP messages it sends. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you > are not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should carry > out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --bcaec548a11904f5d804a4f8445e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bharat,

Draft looks good. Just one minor editorial comment and one clarifi= cation needed below.
=A0
> "DHCP typically identifies clients based on information in t= heir DHCP=A0messages"

You might want to replace the first "DHCP" with DHCP ser= ver. If you do not want to restrict to server here=A0you may=A0say network = entity
=A0
I assume the inclusion of "type" field now is for any future= consideration of including other types like DUID? Else it seems redundant,= now that we have only 1 type in the sub-option.
=A0
Thanks,
Pavan

=A0
On Sun, Jun 5, 2011 at 2:33 PM, Bharat Joshi <bharat_joshi@infosys.com> wrote:
Hi All,

=A0 =A0 =A0This d= raft was under IESG review and a new revision was required as it had three = DISCUSS points. Mark was not getting enough time to push this work. We need= ed this draft for Bulk Lease Query work and so we decided to help.

=A0 =A0 =A0 Apart from the three DISCUSS position, there was a comment = from Ted. Ted had suggested that the usage of DUID as relay-id as defined i= n this draft is not correct. DUID is typically tied down to the device and = the use cases in this draft required same relay-id to be used if a relay-ag= ent is replaced.

=A0 =A0 =A0 =A0In this revision, we have addressed all the DISCUSS posi= tions. We have also removed both the relay-id type ASCII and DUID. We have = introduced a new relay-id type OPAQUE. This new relay-id type can be admini= stratively configured and is a series of octets.

=A0 =A0 =A0 =A0Now, as the above changes are more than minor changes, I= think that it will first have to go through working-group. So I request pe= ople to review this draft ( only 5 pages ) and post their comments.

= Regards,
Bharat
________________________________________
From: dhcwg-bounces@ietf.org [dhcwg-bounces@iet= f.org] On Behalf Of internet-drafts@ietf.org [internet-drafts@ietf.org]
Sent: Saturday, June 04, 2011 10:34 PM
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhc= wg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.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 W= orking Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 := The DHCPv4 Relay Agent Identifier Suboption
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Bharat Joshi
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mark Stapp
=A0 =A0 =A0 =A0Filename =A0 = =A0 =A0 =A0: draft-ietf-dhc-relay-id-suboption-08.txt
=A0 =A0 =A0 =A0Pag= es =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: = 2011-06-04

=A0 This draft defines a new Relay Agent Identifier suboption for the
= =A0 Dynamic Host Configuration Protocol&#39;s (DHCP) Relay Agent Inform= ation
=A0 option. =A0The suboption carries a value that uniquely identif= ies the
=A0 relay agent device within the administrative domain. =A0The value is=A0 typically administratively-configured in the relay agent. =A0The
= =A0 suboption allows a DHCP relay agent to include the identifier in the=A0 DHCP messages it sends.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.= txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc= -relay-id-suboption-08.txt
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http= s://www.ietf.org/mailman/listinfo/dhcwg

**************** CAUTION - Disclaimer *****************
= This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y
for the use of the addressee(s). If you are not the intended recipient= , please
notify the sender by e-mail and delete the original message. Further, you a= re not
to copy, disclose, or distribute this e-mail or its contents to a= ny other person and
any such actions are unlawful. This e-mail may conta= in viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for an= y damage
you may sustain as a result of any virus in this e-mail. You sh= ould carry out your
own virus checks before opening the e-mail or attach= ment. Infosys reserves the
right to monitor and review the content of all messages sent to or from thi= s e-mail
address. Messages sent to or from this e-mail address may be st= ored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaim= er ********INFOSYS***
_______________________________________________
dhcwg mailing list<= br>dhcwg@ietf.orghttps://www.ietf.org/mailman/listinfo/dhcwg

--bcaec548a11904f5d804a4f8445e-- From bharat_joshi@infosys.com Mon Jun 6 02:38:20 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7168611E80D7 for ; Mon, 6 Jun 2011 02:38:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRgfLBG9Y2hf for ; Mon, 6 Jun 2011 02:38:19 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0A11E80D2 for ; Mon, 6 Jun 2011 02:38:18 -0700 (PDT) X-TM-IMSS-Message-ID: <0b23e7f4001f8ce7@infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 0b23e7f4001f8ce7 ; Mon, 6 Jun 2011 15:01:30 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Mon, 6 Jun 2011 15:08:09 +0530 From: Bharat Joshi To: Pavan Kurapati Date: Mon, 6 Jun 2011 15:06:16 +0530 Thread-Topic: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: AcwjkYF5cESoO/qCT46gIJzndwEUPQAm600V Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 09:38:20 -0000 Pavan, Thanks a lot for the quick review. Will rephrase the sentence. Yes. 'type' field has been kept there to keep any future extensibili= ty possible. Regards, Bharat ________________________________________ From: Pavan Kurapati [pavan.kurapati@gmail.com] Sent: Sunday, June 05, 2011 8:31 PM To: Bharat Joshi Cc: dhcwg@ietf.org Subject: Re: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-08.t= xt Bharat, Draft looks good. Just one minor editorial comment and one clarification ne= eded below. > "DHCP typically identifies clients based on information in their DHCP mes= sages" You might want to replace the first "DHCP" with DHCP server. If you do not = want to restrict to server here you may say network entity I assume the inclusion of "type" field now is for any future consideration = of including other types like DUID? Else it seems redundant, now that we ha= ve only 1 type in the sub-option. Thanks, Pavan On Sun, Jun 5, 2011 at 2:33 PM, Bharat Joshi > wrote: Hi All, This draft was under IESG review and a new revision was required as it= had three DISCUSS points. Mark was not getting enough time to push this wo= rk. We needed this draft for Bulk Lease Query work and so we decided to hel= p. Apart from the three DISCUSS position, there was a comment from Ted. = Ted had suggested that the usage of DUID as relay-id as defined in this dra= ft is not correct. DUID is typically tied down to the device and the use ca= ses in this draft required same relay-id to be used if a relay-agent is rep= laced. In this revision, we have addressed all the DISCUSS positions. We ha= ve also removed both the relay-id type ASCII and DUID. We have introduced a= new relay-id type OPAQUE. This new relay-id type can be administratively c= onfigured and is a series of octets. Now, as the above changes are more than minor changes, I think that = it will first have to go through working-group. So I request people to revi= ew this draft ( only 5 pages ) and post their comments. Regards, Bharat ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@= ietf.org] On Behalf Of internet-drafts@ietf.= org [internet-drafts@ietf.org] Sent: Saturday, June 04, 2011 10:34 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : The DHCPv4 Relay Agent Identifier Suboption Author(s) : Bharat Joshi Mark Stapp Filename : draft-ietf-dhc-relay-id-suboption-08.txt Pages : 8 Date : 2011-06-04 This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is typically administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y for the use of the addressee(s). If you are not the intended recipient, ple= ase notify the sender by e-mail and delete the original message. Further, you a= re not to copy, disclose, or distribute this e-mail or its contents to any other p= erson and any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken every reasonable precaution to minimize this risk, but is not liable for an= y damage you may sustain as a result of any virus in this e-mail. You should carry o= ut your own virus checks before opening the e-mail or attachment. Infosys reserves = the right to monitor and review the content of all messages sent to or from thi= s e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Jun 6 06:09:44 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98611E811E for ; Mon, 6 Jun 2011 06:09:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1EEGYMeFIf9 for ; Mon, 6 Jun 2011 06:09:43 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF711E8132 for ; Mon, 6 Jun 2011 06:09:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTezRkh85WsJgsIA1Bb4/RWuW35dF2hG3@postini.com; Mon, 06 Jun 2011 06:09:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7A2B91B8553 for ; Mon, 6 Jun 2011 06:09:38 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6D3CB19005C; Mon, 6 Jun 2011 06:09:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 6 Jun 2011 06:09:37 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset="iso-8859-1" From: Ted Lemon In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com> Date: Mon, 6 Jun 2011 09:09:38 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com> To: Bharat Joshi X-Mailer: Apple Mail (2.1227) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:09:44 -0000 Le Jun 6, 2011 =E0 5:36 AM, Bharat Joshi a =E9crit : > Yes. 'type' field has been kept there to keep any future = extensibility possible. It seems to me that the semantics of DUID are sufficiently different = than the semantics of this option that it would not be useful to combine = them. Do you see some other use for the type field? From bharat_joshi@infosys.com Mon Jun 6 06:18:23 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E54711E813B for ; Mon, 6 Jun 2011 06:18:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U-U6ufKoLrN for ; Mon, 6 Jun 2011 06:18:22 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF311E8138 for ; Mon, 6 Jun 2011 06:18:21 -0700 (PDT) X-TM-IMSS-Message-ID: <4957750700072124@infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4957750700072124 ; Mon, 6 Jun 2011 18:53:30 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Mon, 6 Jun 2011 18:48:19 +0530 From: Bharat Joshi To: Ted Lemon Date: Mon, 6 Jun 2011 18:43:21 +0530 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: AcwkSwi4bUxnfpC0S1ODqZHrOsfWwAAAHnIe Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com>, <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> In-Reply-To: <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:18:23 -0000 >=20>=20=20=20=20=20=20=20Yes.=20'type'=20field=20has=20been=20kept=20the= re=20to=20keep=20any=20future=20extensibility=20possible. >=20 >=20It=20seems=20to=20me=20that=20the=20semantics=20of=20DUID=20are=20suf= ficiently=20different=20than=20the=20semantics=20of=20this=20option=20tha= t=20it=20would=20not=20be=20useful=20to=20combine=20them.=20=20=20Do=20yo= u=20see=20some=20other=20use=20for=20the=20type=20field? >=20 At=20present,=20we=20do=20not=20have=20any=20other=20use=20for=20this=20f= ield.=20This=20'type'=20was=20inspired=20from=20the=20previous=20revision= =20of=20this=20document=20and=20we=20decided=20to=20keep=20it=20there=20t= hinking=20that=20more=20type=20of=20relay-ids=20may=20come=20in=20future. Regards, Bharat ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From Ted.Lemon@nominum.com Mon Jun 6 10:29:06 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE4A11E81A0 for ; Mon, 6 Jun 2011 10:29: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXlVVKJOUMTG for ; Mon, 6 Jun 2011 10:29:06 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3572B11E8174 for ; Mon, 6 Jun 2011 10:28:58 -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 DSNKTe0OWSy0bcSD4+xjltjdeecV0Bv9Tg4t@postini.com; Mon, 06 Jun 2011 10:28: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 803AAF80A6 for ; Mon, 6 Jun 2011 10:28:57 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 79BDC19005D for ; Mon, 6 Jun 2011 10:28:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 6 Jun 2011 10:28:56 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 13:28:53 -0400 Message-ID: To: "dhcwg@ietf.org WG" MIME-Version: 1.0 (Apple Message framework v1227) X-Mailer: Apple Mail (2.1227) Subject: [dhcwg] Agenda items for IETF 81 meeting... X-BeenThere: dhcwg@ietf.org 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, 06 Jun 2011 17:29:06 -0000 I'm pretty sure we are going to need to have a meeting, but what with = the overcrowding of the IETF agenda at recent meetings, they'd like us = to do a slightly better job of figuring out exactly how much time we = need, and what we'll be talking about. So if you plan to have a = discussion at the IETF 81 dhcwg meeting, please send in your request for = time now. Thanks! From tomasz.mrugalski@gmail.com Mon Jun 6 13:07:05 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D111F0C86 for ; Mon, 6 Jun 2011 13:07:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsgp8eQcDBXb for ; Mon, 6 Jun 2011 13:07:04 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADCFE1F0C83 for ; Mon, 6 Jun 2011 13:07:03 -0700 (PDT) Received: by eye13 with SMTP id 13so1986634eye.31 for ; Mon, 06 Jun 2011 13:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=69sJTl6eHpXrSqAMBSuGms8MohVd/mH5Y6xfQ5de7VQ=; b=MCrViDTVswsN/TgutAkL+gEgJ9sIo206pdmUPaV6jyDt4F/0g297RKdvw+EHFEy+I+ /1grHtKVHla9LZ6XC+5mixDqCGNWBXVGv1m7VwCxL2uHWKmjKnt4yAmGHEAzDtkAqjcZ MMFvJRFam2QacKNor0cgx4pGRG9QmKI9jDvpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; b=DT5FEocBLD9s06gpDUub18bV29b2Iuyp8y5DbupzkTL9+ucM1DRMjO6lezjuPgbout tGOLyj/UVhzcQ8Km7IIxwAYTAvkHvbS57yxOohYIWXO5iQQMFzrGN1qhX3AXazWToy0T 2toTgx3+l9TAN5ZiYLB0AMU+RW10ex1QRURCE= Received: by 10.213.26.151 with SMTP id e23mr1085817ebc.118.1307390822682; Mon, 06 Jun 2011 13:07: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 b19sm3399169eec.22.2011.06.06.13.07.01 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 13:07:01 -0700 (PDT) Message-ID: <4DED3365.1070404@gmail.com> Date: Mon, 06 Jun 2011 22:07:01 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: In-Reply-To: X-TagToolbar-Keys: D20110606220701382 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Agenda items for IETF 81 meeting... X-BeenThere: dhcwg@ietf.org 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, 06 Jun 2011 20:07:05 -0000 On 06.06.2011 19:28, Ted Lemon wrote: > I'm pretty sure we are going to need to have a meeting, but what with > the overcrowding of the IETF agenda at recent meetings, they'd like > us to do a slightly better job of figuring out exactly how much time > we need, and what we'll be talking about. So if you plan to have a > discussion at the IETF 81 dhcwg meeting, please send in your request > for time now. I'd like to present four things: 1. DHCPv6 failover requirements document - there is no submitted draft yet, but there are quite a few people working on this right now. We are expecting to submit initial draft before dead-line for Quebec City. It's hard to estimate the actual time, but that's not easy topic, so I suppose at least 20 minutes is required, but your guess is as good as mine. Exact naming is TBD, but it will be similar to draft-something-dhc-dhcpv6-failover-requirements-00.txt. 2. DHCPv6 Route options - There is Route Option defined in draft-ietf-mif-dhcpv6-route-option-01. It is adopted by MIF WG, but it would be good to also present and review it in DHC. There are various opinions on routing configuration over DHCPv6, so at least a bit of discussion is expected. I suppose 10 minutes will suffice. 3. DHCPv6 4rd Options - During Prague meeting, Remi Despres presented proposed DHCPv6 options required for 4rd configuration and requested for involvement from DHC members. I volunteered. There is new draft expected to be submitted soon. draft-mrugalski-dhc-dhcpv6-4rd-00. It's collection of quite simple options, so 5 minutes is probably enough. 4. DHCPv6 suboptions draft - a simple clarification draft about requesting options within other options (by putting instances of ORO within other options). It is draft-mrugalski-dhc-dhcpv6-suboptions-01. It is simple and hopefully not controversial, so 5 minutes is probably ok. Note: All of those draft already are or will soon be discussed on mailing list. Thanks, Tomek From tomasz.mrugalski@gmail.com Mon Jun 6 14:39:10 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2DC11E81AB for ; Mon, 6 Jun 2011 14:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivHutLELupip for ; Mon, 6 Jun 2011 14:39:09 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56BBC11E81A9 for ; Mon, 6 Jun 2011 14:39:09 -0700 (PDT) Received: by ewy19 with SMTP id 19so2014639ewy.31 for ; Mon, 06 Jun 2011 14:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=DuUZp16grOWk/Q/232jKJi4H4Zd8S+OwLXTWINPT7Hg=; b=msyfJdTrOd6GXUVMHtbA54Vy0WfguGgD/FadBe7bJLLPbF38NFXnOh0oZNLL0SXjdA ZjFbeNftWzx9RLxc9ZB7nCkgzFJZ3oluOtHo9rdT5J+76PBvSKKONp58vw3E85oIQWIK hFId1zSyN4o9x1Nik22Yr90yB7haKbJKTao6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=iqXl6janhcyfptFclCitcWUaHCzXlC2hvdHq0FoXnfJxg+OJiqy0RRPVcIPW5j8g1p 6eu40j8sPiN/KPj4UeTls0G7kABJz4viWDzgBZ0jh7MNT8OMGI/u5ssgSqr/krTADbh4 bpFkWoVjue9Fk+WxDL5Mg6ABgHrQ99+jqLZCk= Received: by 10.14.17.194 with SMTP id j42mr2093268eej.81.1307396346797; Mon, 06 Jun 2011 14:39:06 -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 q42sm3446769eej.27.2011.06.06.14.39.04 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 14:39:05 -0700 (PDT) Message-ID: <4DED48F8.4050705@gmail.com> Date: Mon, 06 Jun 2011 23:39:04 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Failover 2011-06-06 meeting minutes X-BeenThere: dhcwg@ietf.org 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, 06 Jun 2011 21:39:11 -0000 Here are the minutes from initial DHCPv6 Failover requirements meeting. Invitations to that meeting were sent to anyone who responded to my request for participation, previously announced on DHC mailing list: http://www.ietf.org/mail-archive/web/dhcwg/current/msg11652.html Ted Lemon pointed out that this is not acceptable approach, so I'd like to announce that this was only the first one in a series of weekly meetings. The next meeting is tentatively scheduled for: Monday, 2011-06-13 10:00 PDT Bridge info will be sent out shortly to all who expressed interest in this work and to the list as well. Please contact me if you want to receive current copy of the draft, have comments, suggestions, agenda items for next meeting or would like to state your preferred schedule. Note: This is preparatory work for initial draft. You are welcome to join in if you want to participate in this work from the very beginning, even before initial submission. Regards, Tomek DHCPv6 Failover requirements meeting - 2011-06-06 --------------------------------------------------- Participants: 1. Jack Chen (Time Warner Cable) 2. Kim Kinnear (Cisco) 3. Alain Maes (Alcatel Lucent) 4. Tomek Mrugalski (ISC) 5. Shawn Routher (ISC) 0. Announcement Ted Lemon asked to be sure that all meetings are announced on the DHC WG mailing list, and that minutes (if any) are also distributed there. 1. Agenda bashing No changes to the agenda sent in the email 2. Work flow (how to organize work) a) sending comments, editor updates b) token based Discussion of how to do the editing - one editor accepting changes vs token approach of multiple people doing the editing and passing a token around as to who is doing the editing. Shawn said that he thought that documents were more consistent if one person edited them. Kim said that he thought that the requirements document was short enough that having a single editor was probably ok, but that in a longer document we might want to pass the token as necessary. Sometimes it is a lot easier to edit the changes and let people see them as diffs as opposed to sending in change after change. Currently planning on one editor managing the work (Tomek). 3. Meeting schedule and deadline Due date for this document is July 4. Weekly calls? Consensus: Yes. Kim and Tomek offered webex, nobody seemed to need it. Tomek suggested people send preferences on times to him. No preferences received so far. Planning on weekly calls, currently planning on using the ISC bridge but may switch to webex if that is more convenient for people. 4. Next steps after requirements document? a. Design Document b. Protocol Document Considerable discussion ensued. Overall, seemed like the discussion came around to: focus first on design, then on protocol if there is still energy and need for it. Shawn said that if the design was 10 pages, then having it on the front of the protocols document would make less to get through IETF. Kim said that the v4 failover document was just so long that it couldn't make it though, and having the design approved would make it a lot easier to get the protocol pushed through. Kim also brought up the issue of whether there is a consensus about needing an intervendor protocol document (which is protocol documents at IETF are typically about). One of the problems with getting the v4 protocol document through was that there wasn't a huge amount of desire for an intervendor protocol -- i.e., a protocol that would work with the main server from one vendor and the back from a different vendor. The other folks on the call agreed that we haven't to date, seen much customer pressure for this in the DHCPv4 space. There seems to be strong pressure to have a failover option but there does not seem to be pressure to have an interoperable specification between different vendors. (Corrections from the user community would be quite useful at this time.) That doesn't mean that we can't do a DHPCv6 protocol spec, but it does mean that this is an issue we need to work through. Current feeling seems to be to plan for 3 docuemnts requirements, design and protocol. If it makes sense to collapse the last two (design and protocol) into a single document that would be something to consider but that should be deteremined when we get part/most of the way through the design. 5. Discussion of comments received so far a. Make it clear that m-m is not applicable, and 1-1 is the goal. Each IP address or prefix is handled by at most two servers in a failover pair. We had a discussion about whether any server should be allowed to be in more than one failover pair. The v4 version allows for one server to be in multiple pairwise failover relationships. This allows for a central or back office approach. This seems like a good idea in theory but has some drawbacks in practice. Getting more feedback from actual large users about such use would be good. b. There was a question about "lease stability", and whether that was a goal. That is *already* a goal in the document, and consensus was that it should certainly stay as a goal. Agreement that the v6 version should include support for prefix delegation. c. How many servers "know" about one IP address? Two was the answer. d. VRRP: Frank Sweeter said that the DHCPv6 multicast covered this case. Kim suggested that we believe that until and unless someone comes up with more specifics than "you should look at this RFC". e. We should put something in the document about whether or not we are planning to handle network partition events. Kim said that a large (maybe 30%) of the DHCPv4 failover document is involved in handling network partition events. Thus, we don't want to take on that work lightly. Kim said that while these events are rare, they do come up. There was some linkage of network partition events with geographical distribution of failover servers, since it is obviously easier to have such events if the failover servers are not in the same place. Shawn said that until recently, he would not have thought that anyone really cared about network partition events, but after talking to some customers recently, he now believes that it is important to handle this situation. Shawn said that it would be nice if people could enable or disable the code to handle network partition events, but if that wasn't possible or made things too difficult, then he would understand that it has to be built into every implementation. Discussion of network partition vs partner down. We think there are probably two basic groups - large enterprises and ISPs that probably want geographic separation and either are willing to pay for it or already have the facilities set up - smaller enterprises that may have a single campus (even a large campus) and are content to have multiple servers but not widely separated, for example 2 servers in the same machine room. There seems to be agreement that we do need to support network partition. We may be able to do this as an option. Discussion of lock step vs lazy update. There is general agreement that lock step isn't viable. Performance penalty was one of the reasons. f. Discussed new items for the section 4 requirements; i. Network partition - add ii. Lazy update - add iii. Load balancing must at least be considered, but at least Kim and Tomek felt that load balancing should actually be documented in a separate document. Nobody else expressed much of opinion on this. g. General consensus on the fact that the DHCPv6 failover will replicate the information in the lease state database. 6. Discussion on authors Otherwise known as "whose name is on the draft". Tomek said that 12 people responded as wanting to help, and that was to many to have as authors. Shawn said that he felt that Tomek should be the "editor", everyone else should be a contributor mentioned in toward the end of the document. Kim said that, at the time the draft was submitted, that it was unlikely that 12 people would have participated, and that it would make sense to put the people who really contributed as authors of the draft. 7. extra topics What about the promise of v6 - that we can simple move from a valid to a new preferred address? Given that we are using DHCP instead of autoconf this doesn't seem to have gotten far enough yet. The reality seems to be that end users want and providers want to provide address stickiness - that the end user continues to get the same address when possible. Prefix delegation is also an issue in this. 8. Invited participants: - Kris Bransom (Comcast) - John Brzozowski (Comcast) - Jack Chen (Time Warner Cable) - Gaurav Halwasia (Cisco) - David Hankins (Google) - Kim Kinnear (Cisco) - Suresh Krishnan (Ericsson) - Ted Lemon (Nominum) - Alain Maes (Alcatel Lucent) - Tomasz Mrugalski (ISC) - Jiang Sheng (Huawei) - Frank Sweetser (Worcester Polytechnic Institute) - Shawn Routher (ISC) - Jean-Francois Tremblay (Videotron) - Bernie Volz (Cisco) - Qin Wu (Huawei) Thanks to Shawn and Kim for providing excellent minutes. From gwz@net-zen.net Tue Jun 7 20:06:56 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936D21F85F7 for ; Tue, 7 Jun 2011 20:06:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ASU5gAIasvd for ; Tue, 7 Jun 2011 20:06:55 -0700 (PDT) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by ietfa.amsl.com (Postfix) with SMTP id EF85B21F85F4 for ; Tue, 7 Jun 2011 20:06:54 -0700 (PDT) Received: (qmail 28711 invoked from network); 8 Jun 2011 03:06:54 -0000 Received: from unknown (124.121.219.11) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 08 Jun 2011 03:06:54 -0000 Message-ID: <4DEEE749.8000304@net-zen.net> Date: Wed, 08 Jun 2011 10:06:49 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: draft-ietf-dhc-dhcpv6-relay-supplied-options@tools.ietf.org, The IESG X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060304090503020504050806" Cc: "dhc-chairs@ietf.org" , "dhcwg@ietf.org WG" Subject: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv6-relay-supplied-options X-BeenThere: dhcwg@ietf.org 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, 08 Jun 2011 03:06:56 -0000 This is a multi-part message in MIME format. --------------060304090503020504050806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Section 8, paragraph 2 says: We request that the IANA create a new registry on the same assignments page, titled "Options Permitted in the Relay-Supplied Options Option". This option will contain a list of names of options from the DHCP Option Codes list. s/This option/This registry Currently, the list is empty. Options may be added to this list either as a result of protocol action or expert review. Expert review may either be in the form of a working group review and consensus call, or IESG review in consultation with the DHC working group chair or chairs. This policy apparently assumes either a) the eternal nature of the dhc WG or b) the formation of a new WG just for the evaluation of RSOO-enabled options. Neither assumption seems particularly valid. --------------060304090503020504050806 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------060304090503020504050806-- From tomasz.mrugalski@gmail.com Wed Jun 8 04:22:56 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB711E80E4 for ; Wed, 8 Jun 2011 04:22:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJqis2xyVdlh for ; Wed, 8 Jun 2011 04:22:56 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7111E80B2 for ; Wed, 8 Jun 2011 04:22:55 -0700 (PDT) Received: by pxi20 with SMTP id 20so302333pxi.27 for ; Wed, 08 Jun 2011 04:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wMNn1r1hEKhJTLeG9D8Snv7q4OavZMViqgkvks9S/pM=; b=cdsB1SNRoLbUnyL0vOs68wmQILGFvv7HJQZbBBpzYPAHgbDEszrwfYRGyLYJ78RacL tGqTzsgwaUIWkLXfWJNibhxa1DbslyDnZpanx9ng5SYDD19vQA/LiqZ6LGo1KwIKJMmn noP9qn+qm9MuAD/JTlTh2gihwfTR/JfReU+f8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LbvE5h/qzkxy2VBtp3qvAIVqvGOwFrXjBwUR1Es/3c83Zs2i2PunOdXhsXS5KEz7DZ 7o7ni9bmy0jdhV0surNYEyuIjbCyfq7n11i2PuZkX/NQFmKDIrsvbDHUpKxPFRXvLVls aXtGRmOHgz0jzweg6j2Gei8TWxO7Bq7cvdwCc= MIME-Version: 1.0 Received: by 10.68.65.40 with SMTP id u8mr702356pbs.229.1307532174842; Wed, 08 Jun 2011 04:22:54 -0700 (PDT) Received: by 10.68.52.99 with HTTP; Wed, 8 Jun 2011 04:22:54 -0700 (PDT) In-Reply-To: <2E8D95DF84AB9940BDCB9ADA899BBE30035A75@usemp111.ins.com> References: <4DED48F8.4050705@gmail.com> <2E8D95DF84AB9940BDCB9ADA899BBE30035A75@usemp111.ins.com> Date: Wed, 8 Jun 2011 13:22:54 +0200 Message-ID: From: Tomasz Mrugalski To: Greg.Rabil@usc-bt.com Content-Type: text/plain; charset=ISO-8859-1 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Failover 2011-06-06 meeting minutes X-BeenThere: dhcwg@ietf.org 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, 08 Jun 2011 11:22:56 -0000 On 11-06-07 17:50, Greg.Rabil@usc-bt.com wrote: > Sorry I missed this discussion. I would have liked to attend, but I > was travelling yesterday. Next meeting is scheduled for June 13, Monday 10:00 PST (19:00 CEST). I will send out bridge info and agenda shortly before the meeting. > As one of the original authors of the DHCPv4 Failover draft, I would > like to participate in these discussions going forward. I would echo Great! Welcome aboard. > many of Kim's comments about that v4 draft. What started as a simple > solution became an extremely bloated spec that stood no chance of > making it through the IETF. Yes, I agree completely. That's why we are trying to do this in smaller pieces. Current plan is to have: 1. requiremenst document 2. design document 3. protocol spec document We will try to push any non-mandatory features to separate extension documents. By non-mandatory I mean features that are not required in some scenarios. > I believe that any documents that we create should provide some > clarification about when it is appropriate to use failover, and when > it may not be. For example, if there is no real strict need for the > client to maintain the same IP address, then the 'preference' option > could be used to provide some level of redundancy. Also, in cases > where DHCP is used briefly for a bootstrapping clients (i.e. PXE), > failover may not be appropriate for this setup. Good points. I'll add small section that explains this. Tomek From iesg-secretary@ietf.org Wed Jun 8 06:39:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2AD11E80FD; Wed, 8 Jun 2011 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO9gig+LO95N; Wed, 8 Jun 2011 06:39:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37111E80EA; Wed, 8 Jun 2011 06:39:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110608133925.25307.67302.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 06:39:25 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Subnet Allocation Option) to Informational RFC X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:39:26 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Subnet Allocation Option' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-22. 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 a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/811/ From alexandru.petrescu@gmail.com Wed Jun 8 07:30:02 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC511E80E3; Wed, 8 Jun 2011 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU6+eDsc8Ub8; Wed, 8 Jun 2011 07:29:57 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6745711E8094; Wed, 8 Jun 2011 07:29:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p58ETtL4001961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jun 2011 16:29:55 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p58ETs40025921; Wed, 8 Jun 2011 16:29:54 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p58ETsAo023608; Wed, 8 Jun 2011 16:29:54 +0200 Message-ID: <4DEF8762.1090404@gmail.com> Date: Wed, 08 Jun 2011 16:29:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf@ietf.org References: <20110608133925.25307.67302.idtracker@ietfa.amsl.com> In-Reply-To: <20110608133925.25307.67302.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dhcwg@ietf.org, The IESG Subject: Re: [dhcwg] Last Call: (Subnet Allocation Option) to Informational RFC X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:30:03 -0000 I have read parts of the document and I find it ok. > The DHCP Server SHOULD allocate a subnet with prefix size less than > or equal to the size P specified in the request. In other words, a > subnet at least the size requested and possibly bigger. I agree, but "prefix size less than or equal to the size P" is not very clear, because (1) there is no "P" in the request but "Prefix", "size" is hard to understand, etc. Maybe it should say "the length of the allocated prefix should have a value non-zero and less than or equal to value Prefix in the Request; e.g. if the Request demands a prefix of length 4 the response MUST be of length any of 1, 2, 3 or 4". There is another point which I think is not discussed in this draft. Contrary to allocation of an address, always the Relay and sometimes the Server _must_ update their forwarding/routing tables, according to a specific rule [subnet,IPaddress], when this allocation of a subnet prefix is performed - otherwise packet forwarding won't work (packets don't reach the Host allocated an address from this prefix). typo " qis " on page 4. Alex Le 08/06/2011 15:39, The IESG a écrit : > > The IESG has received a request from the Dynamic Host Configuration > WG (dhc) to consider the following document: - 'Subnet Allocation > Option' as an Informational > RFC > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send substantive > comments to the ietf@ietf.org mailing lists by 2011-06-22. > 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 a new DHCP option which is passed between the > DHCP Client and the DHCP Server to request dynamic allocation of a > subnet, give specifications of subnet(s) allocated, and report usage > statistics. This memo documents the current usage of the option in > agreement with [RFC3942], which declares that any pre-existing > usages of option numbers in the range 128 - 223 should be documented > and the working group will try to officially assign those numbers to > those options. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/811/ > > > > _______________________________________________ IETF-Announce mailing > list IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From Ted.Lemon@nominum.com Wed Jun 8 10:57:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2B11E81BA for ; Wed, 8 Jun 2011 10:57: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+b0xiQCIup7 for ; Wed, 8 Jun 2011 10:57:25 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id D72CC11E8095 for ; Wed, 8 Jun 2011 10:57:24 -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 DSNKTe+4BLYAUE7uFqSitgrXbK7/UwtZuHjU@postini.com; Wed, 08 Jun 2011 10:57: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 D8EEAF8050 for ; Wed, 8 Jun 2011 10:57:23 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CBB01190059; Wed, 8 Jun 2011 10:57:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Jun 2011 10:57:23 -0700 MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com> Date: Wed, 8 Jun 2011 13:57:19 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com>, <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com> To: Bharat Joshi X-Mailer: Apple Mail (2.1237.1) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:57:25 -0000 On Jun 6, 2011, at 9:13 AM, Bharat Joshi wrote: > At present, we do not have any other use for this field. This 'type' = was inspired from the previous revision of this document and we decided = to keep it there thinking that more type of relay-ids may come in = future. I think the bottom line is that if you can't figure out what the type = field does, you should take it out. We are not experiencing a shortage = of DHCPv6 option codes, so there's no reason to keep complexity in the = spec to account for an unknown future circumstance that may or may not = come to exist. From leaf.y.yeh@huawei.com Wed Jun 8 19:29:41 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F415211E8084 for ; Wed, 8 Jun 2011 19:29:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxV1v6dCe0uE for ; Wed, 8 Jun 2011 19:29:40 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6BB11E8074 for ; Wed, 8 Jun 2011 19:29:40 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMI001AW48VW0@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 09 Jun 2011 10:29:19 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMI006TC48V00@szxga03-in.huawei.com> for dhcwg@ietf.org; Thu, 09 Jun 2011 10:29:19 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 09 Jun 2011 10:29:18 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.169]) by szxeml407-hub.china.huawei.com ([169.254.34.53]) with mapi id 14.01.0270.001; Thu, 09 Jun 2011 10:29:19 +0800 Date: Thu, 09 Jun 2011 02:29:18 +0000 From: Leaf yeh In-reply-to: <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> X-Originating-IP: [10.70.39.133] To: Ted Lemon , Bharat Joshi Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-index: AQHMJEsx+z9Vr7dJOkyY/x4G0YREuZSvyFGAgAN0AICAARL5gA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com> <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com> <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:29:41 -0000 Ted - We are not experiencing a shortage of DHCPv6 option codes,... Supposed you're talking about the space shortage of the DHCPv4 option codes. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, June 09, 2011 1:57 AM To: Bharat Joshi Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt On Jun 6, 2011, at 9:13 AM, Bharat Joshi wrote: > At present, we do not have any other use for this field. This 'type' was inspired from the previous revision of this document and we decided to keep it there thinking that more type of relay-ids may come in future. I think the bottom line is that if you can't figure out what the type field does, you should take it out. We are not experiencing a shortage of DHCPv6 option codes, so there's no reason to keep complexity in the spec to account for an unknown future circumstance that may or may not come to exist. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From alexandru.petrescu@gmail.com Thu Jun 9 02:44:39 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D80B11E8071 for ; Thu, 9 Jun 2011 02:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Jlb15SZvde for ; Thu, 9 Jun 2011 02:44:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id AB508228003 for ; Thu, 9 Jun 2011 02:44:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p599iXM9026386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Jun 2011 11:44:33 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p599iWK8028851; Thu, 9 Jun 2011 11:44:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p599iWrH018941; Thu, 9 Jun 2011 11:44:32 +0200 Message-ID: <4DF09600.8070209@gmail.com> Date: Thu, 09 Jun 2011 11:44:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com> <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com> <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 09:44:39 -0000 Le 09/06/2011 04:29, Leaf yeh a écrit : > Ted - We are not experiencing a shortage of DHCPv6 option codes,... Yes, we use 66 decimal 0x42 for a new yet-to-be-documented option, we think 66 may be the first available (IANA, isc sw) and max seems to be 255 even though 1 more byte can there be. Alex > > Supposed you're talking about the space shortage of the DHCPv4 > option codes. > > > > -----Original Message----- From: dhcwg-bounces@ietf.org > [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: > Thursday, June 09, 2011 1:57 AM To: Bharat Joshi Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-relay-id-suboption-08.txt > > On Jun 6, 2011, at 9:13 AM, Bharat Joshi wrote: >> At present, we do not have any other use for this field. This >> 'type' was inspired from the previous revision of this document >> and we decided to keep it there thinking that more type of >> relay-ids may come in future. > > I think the bottom line is that if you can't figure out what the > type field does, you should take it out. We are not experiencing a > shortage of DHCPv6 option codes, so there's no reason to keep > complexity in the spec to account for an unknown future circumstance > that may or may not come to exist. > > > _______________________________________________ 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 bharat_joshi@infosys.com Thu Jun 9 03:19:20 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5028A11E80B5 for ; Thu, 9 Jun 2011 03:19:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5QDcOSe5ofr for ; Thu, 9 Jun 2011 03:19:19 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id 349D211E80E8 for ; Thu, 9 Jun 2011 03:19:18 -0700 (PDT) X-TM-IMSS-Message-ID: <5833c5ef0009afd5@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 5833c5ef0009afd5 ; Thu, 9 Jun 2011 15:50:39 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub01.ad.infosys.com ([10.66.236.41]) with mapi; Thu, 9 Jun 2011 15:49:16 +0530 From: Bharat Joshi To: Ted Lemon Date: Thu, 9 Jun 2011 15:49:15 +0530 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: AcwmBYscyg+9X6J4QDuCsDxnqxGUSAAiEX74 Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F21@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com>, <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com>, <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> In-Reply-To: <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 10:19:20 -0000 Ted, >>=20At=20present,=20we=20do=20not=20have=20any=20other=20use=20for=20thi= s=20field.=20This >>=20'type'=20was=20inspired=20from=20the=20previous=20revision=20of=20th= is=20document >>=20and=20we=20decided=20to=20keep=20it=20there=20thinking=20that=20more= =20type=20of >>=20relay-ids=20may=20come=20in=20future. > >=20I=20think=20the=20bottom=20line=20is=20that=20if=20you=20can't=20figu= re=20out=20what=20the >=20type=20field=20does,=20you=20should=20take=20it=20out.=20=20=20We=20a= re=20not=20experiencing=20a >=20shortage=20of=20DHCPv6=20option=20codes,=20so=20there's=20no=20reason= =20to=20keep >=20complexity=20in=20the=20spec=20to=20account=20for=20an=20unknown=20fu= ture=20circumstance >=20that=20may=20or=20may=20not=20come=20to=20exist. BTW,=20we=20are=20looking=20at=20DHCPv4=20here.=20We=20have=20used=20up= =2011=20sub-option=20numbers=20as=20of=20now=20and=20so=20we=20still=20ha= ve=20around=20244=20available. If=20we=20are=20not=20worried=20about=20the=20number=20of=20sub-options= =20then=20we=20can=20remove=20the=20'type'=20field.=20The=20only=20other= =20reason=20for=20keeping=20'type'=20field=20was=20to=20keep=20all=20type= =20of=20relay-id=20under=20one=20single=20sub-option. Let=20me=20know=20what=20do=20you=20think. Regards, Bharat ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From rdroms.ietf@gmail.com Fri Jun 10 20:55:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ED69E8011; Fri, 10 Jun 2011 20:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqy582QkoTbU; Fri, 10 Jun 2011 20:55:23 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2AC9E800B; Fri, 10 Jun 2011 20:55:22 -0700 (PDT) Received: by bwz13 with SMTP id 13so3114869bwz.31 for ; Fri, 10 Jun 2011 20:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=GX/Lxk7OaHJ0mDZAN5VPC/orKJwvhWCN1XAG44pgxfk=; b=TCQ6d1WV/GEDgVuZIShnVsL56sxy/sccARQC2XRaAipqn4T1ChAiox9wt3VthG6LlS fyyWaldbqkLRSV7PWn/+YxFmtohTAEwaCUvZIApLRnh9OLJci4k5XMJurgICkhtlXxIH NOEJSq3MDj8PyCqggrSIRWz0YgqfJn0W3Ct+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=aPsrU/vmK9sUmpyL7MwUA2Fk0CUXEXk/NI+U6Dkw8/7xpiZXSBSJcO8ZWDgz3AY8RK tCaCUoHJd66dIFhlZ/9aVbxwZ92x/pOS/pMBs+TgB5NGgm+BmDg65wIMliA9s2ObPMOq yK/K9NIVV5iayqEdO5DewWRGpnRcgOlwqI+Jw= Received: by 10.205.82.80 with SMTP id ab16mr2521109bkc.66.1307764521047; Fri, 10 Jun 2011 20:55:21 -0700 (PDT) Received: from [172.30.28.243] ([80.187.195.47]) by mx.google.com with ESMTPS id af13sm3150085bkc.7.2011.06.10.20.55.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2011 20:55:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4DEEE749.8000304@net-zen.net> Date: Fri, 10 Jun 2011 20:29:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4DEEE749.8000304@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: "dhc-chairs@ietf.org" , Ralph Droms , "dhcwg@ietf.org WG" , draft-ietf-dhc-dhcpv6-relay-supplied-options@tools.ietf.org, The IESG Subject: Re: [dhcwg] Mail regarding draft-ietf-dhc-dhcpv6-relay-supplied-options X-BeenThere: dhcwg@ietf.org 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, 11 Jun 2011 03:55:25 -0000 Glen - thanks for your review and feedback. - Ralph On Jun 8, 2011, at 5:06 AM 6/8/11, Glen Zorn wrote: > Section 8, paragraph 2 says: > > We request that the IANA create a new registry on the same > assignments page, titled "Options Permitted in the Relay-Supplied > Options Option". This option will contain a list of names of options > from the DHCP Option Codes list. > > s/This option/This registry Authors, please make this fix in the next revision. > > Currently, the list is empty. > Options may be added to this list either as a result of protocol > action or expert review. Expert review may either be in the form of > a working group review and consensus call, or IESG review in > consultation with the DHC working group chair or chairs. > > This policy apparently assumes either a) the eternal nature of the dhc > WG or b) the formation of a new WG just for the evaluation of > RSOO-enabled options. Neither assumption seems particularly valid. > The IANA registry text will be revised to specify a policy based on RFC 5226. From volz@cisco.com Sun Jun 12 13:03:57 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ED211E8130 for ; Sun, 12 Jun 2011 13:03: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v25A3ZAroPaz for ; Sun, 12 Jun 2011 13:03:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id CF9B711E80E9 for ; Sun, 12 Jun 2011 13:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=4193; q=dns/txt; s=iport; t=1307909035; x=1309118635; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NEDrdGz+xr/iRfjoj6nF3/iPDh6nW8xCk1PeVI8LUYQ=; b=MdVLoygkiuze0yEcoSsQ0S2SGK860bFaHFIeTBAE8nZY2emtEiz6zacH LVei88XsLpJ2Go1twvbhgoUbstZqtP306lQzIJXZ9ZmWLQSWZr2XnQV6n Du1NNPuOE5OMAbpInSgzObcxCYfJ+Y0+ZDw6XW4WsUCdwpcxjGq8nlntb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBAPga9U2tJV2a/2dsb2JhbABSl1eOeHeqbZx8hiQEhw2Of4sj X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="464092214" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2011 20:03:55 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5CK3tWd003897; Sun, 12 Jun 2011 20:03:55 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 15:03:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 15:03:51 -0500 Message-ID: In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwi2YMzGEKrsYkCTqOR+0a/a2b14QEgKCViAHfPjsA= References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com> From: "Bernie Volz (volz)" To: "Bharat Joshi" X-OriginalArrivalTime: 12 Jun 2011 20:03:55.0054 (UTC) FILETIME=[DB92C4E0:01CC293B] Cc: dhcwg@ietf.org, "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 20:03:57 -0000 Hi ... I've decided to add the DHC WG as this is a document being worked on there. Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger argument for this).=20 And, I doubt the IESG will be happy with this document and leaving the actual identifier as completely opaque! How would this identifying data be assured to be unique if it is just defined as a 'series of octets'? I also fail to see why the DUID isn't being recommended as the standard format for this relay identifier? See RFC 5460 section 5.4, OPTION_RELAY_ID. And, thus do we really need a type field in the option? Isn't just a DUID sufficient? I'd also say that for "compatibility" with DHCPv6, using the DUID as the relay identifier too would be really convenient and appropriate. This also means section 6 can probably be significantly scaled back - the only issue is the unicast RENEW. - Bernie -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com]=20 Sent: Friday, June 10, 2011 6:36 AM To: Bernie Volz (volz) Subject: FW: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Bernie, Mark told me that you had reviewed this draft and had provided valuable inputs. We have made quiet a few changes from the last revision. Can you please review this new revision and send any comments to DHC mailing list? We need this draft for our 'DHCPv4 Bulk lease query' draft. Thanks in advance, Bharat ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Saturday, June 04, 2011 10:34 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.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 : The DHCPv4 Relay Agent Identifier Suboption Author(s) : Bharat Joshi Mark Stapp Filename : draft-ietf-dhc-relay-id-suboption-08.txt Pages : 8 Date : 2011-06-04 This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is typically administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08 .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08. txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely=20 for the use of the addressee(s). If you are not the intended recipient, please=20 notify the sender by e-mail and delete the original message. Further, you are not=20 to copy, disclose, or distribute this e-mail or its contents to any other person and=20 any such actions are unlawful. This e-mail may contain viruses. Infosys has taken=20 every reasonable precaution to minimize this risk, but is not liable for any damage=20 you may sustain as a result of any virus in this e-mail. You should carry out your=20 own virus checks before opening the e-mail or attachment. Infosys reserves the=20 right to monitor and review the content of all messages sent to or from this e-mail=20 address. Messages sent to or from this e-mail address may be stored on the=20 Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From jiangsheng@huawei.com Sun Jun 12 20:49:13 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658301F0C40 for ; Sun, 12 Jun 2011 20:49:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrHKpPPOsOxy for ; Sun, 12 Jun 2011 20:49:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 77F831F0C3B for ; Sun, 12 Jun 2011 20:49:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP001I5MK32N@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 13 Jun 2011 11:48:03 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP00D94MJWUK@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 13 Jun 2011 11:48:03 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 11:48:00 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.3]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Mon, 13 Jun 2011 11:47:47 +0800 Date: Mon, 13 Jun 2011 03:46:42 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.101] To: Ted Lemon , "dhcwg@ietf.org WG" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92860551@SZXEML504-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Agenda items for IETF 81 meeting... Thread-index: AQHMJG9cVDdeW+5xY0+ZiutYJ3pyYJS6r/FA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [dhcwg] Agenda items for IETF 81 meeting... X-BeenThere: dhcwg@ietf.org 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, 13 Jun 2011 03:49:13 -0000 Hi, Ted & John, draft-ietf-dhc-secure-dhcpv6 has been WG draft for a while and is quite stable. I would like to briefly present it in IETF 81 meeting and request to move to WGLC. I think 5 mins slot can work. Many thanks. Best regards, Sheng > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ted Lemon > Sent: Tuesday, June 07, 2011 1:29 AM > To: dhcwg@ietf.org WG > Subject: [dhcwg] Agenda items for IETF 81 meeting... > > I'm pretty sure we are going to need to have a meeting, but what with > the overcrowding of the IETF agenda at recent meetings, they'd like us > to do a slightly better job of figuring out exactly how much time we > need, and what we'll be talking about. So if you plan to have a > discussion at the IETF 81 dhcwg meeting, please send in your request > for time now. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From bharat_joshi@infosys.com Sun Jun 12 23:45:29 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EA611E809C for ; Sun, 12 Jun 2011 23:45:29 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZKlT0pD1Nww for ; Sun, 12 Jun 2011 23:45:29 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 83BE211E808D for ; Sun, 12 Jun 2011 23:45:28 -0700 (PDT) X-TM-IMSS-Message-ID: <2e920fcb00231bc6@infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2e920fcb00231bc6 ; Mon, 13 Jun 2011 12:08:31 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Mon, 13 Jun 2011 12:15:26 +0530 From: Bharat Joshi To: "Bernie Volz (volz)" Date: Mon, 13 Jun 2011 12:15:25 +0530 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwi2YMzGEKrsYkCTqOR+0a/a2b14QEgKCViAHfPjsAAFqWMwQ== Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 06:45:29 -0000 Hi=20Bernie, =20=20=20=20=20Thanks=20a=20lot=20for=20the=20quick=20review.=20Please=20= see=20my=20response=20in=20line. Regards, Bharat >Hi=20...=20I've=20decided=20to=20add=20the=20DHC=20WG=20as=20this=20is= =20a=20document=20being=20worked >=20on=20there. Yes.=20No=20issues. >=20Personally,=20I'd=20switch=20section=203.1=20and=203.2=20(bulk=20LQ= =20is=20a=20much=20stronger >=20argument=20for=20this).=20 That=20make=20sense.=20I=20can=20surely=20do=20this=20in=20next=20revisio= n. >=20And,=20I=20doubt=20the=20IESG=20will=20be=20happy=20with=20this=20doc= ument=20and=20leaving=20the >=20actual=20identifier=20as=20completely=20opaque!=20=20How=20would=20th= is=20identifying=20data >=20be=20assured=20to=20be=20unique=20if=20it=20is=20just=20defined=20as= =20a=20'series=20of=20octets'? The=20draft=20suggest=20that=20this=20opaque=20identifier=20be=20administ= ratively=20configured=20and=20there=20should=20be=20a=20mean=20to=20displ= ay=20this=20to=20the=20administrator.=20So=20we=20expect=20administrator= =20to=20be=20able=20to=20take=20care=20of=20keeping=20it=20unique=20in=20= their=20own=20administrative=20domain. >=20I=20also=20fail=20to=20see=20why=20the=20DUID=20isn't=20being=20recom= mended=20as=20the=20standard >=20format=20for=20this=20relay=20identifier?=20See=20RFC=205460=20sectio= n=205.4, >=20OPTION_RELAY_ID. The=20previous=20version=20of=20this=20draft=20had=20suggested=20the=20us= e=20of=20DUID.=20But=20we=20had=20to=20remove=20it=20because=20our=20use= =20cases=20required=20that=20same=20relay-id=20be=20used=20even=20if=20th= e=20device=20is=20replaced. >=20And,=20thus=20do=20we=20really=20need=20a=20type=20field=20in=20the= =20option?=20Isn't=20just=20a >=20DUID=20sufficient? That=20'type'=20field=20was=20kept=20from=20the=20previous=20revision,=20= for=20the=20future=20extensibility.=20At=20present,=20we=20feel=20that=20= an=20opaque=20relay-id=20fulfils=20works=20for=20our=20use-cases=20but=20= in=20future=20that=20may=20be=20other=20use-cases=20which=20might=20want= =20to=20use=20a=20different=20type=20of=20relay-id. In=20fact,=20Ted=20and=20Pavan=20had=20a=20similar=20comments.=20If=20mos= t=20of=20the=20people=20feel=20that=20we=20can=20define=20a=20new=20sub-o= ption=20when=20such=20a=20requirements=20comes,=20we=20can=20remove=20thi= s=20'type'=20field. >=20I'd=20also=20say=20that=20for=20"compatibility"=20with=20DHCPv6,=20us= ing=20the=20DUID=20as=20the >=20relay=20identifier=20too=20would=20be=20really=20convenient=20and=20a= ppropriate.=20This >=20also=20means=20section=206=20can=20probably=20be=20significantly=20sc= aled=20back=20-=20the >=20only=20issue=20is=20the=20unicast=20RENEW. I=20am=20not=20sure=20if=20using=20DUID=20for=20the=20use-cases=20mention= ed=20in=20this=20draft=20will=20be=20appropriate.=20 We=20had=20to=20come=20out=20with=20this=20new=20revision=20because=20it= =20was=20pointed=20out=20that=20DUID=20cannot=20be=20used=20where=20same= =20id=20is=20required=20even=20when=20the=20devices=20are=20replaced. Once=20we=20decide=20upon=20whether=20we=20can=20use=20DUID=20or=20not,= =20we=20can=20discuss=20other=20points=20which=20you=20have=20raised=20he= re. ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From volz@cisco.com Mon Jun 13 05:59:55 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468D81F0C63 for ; Mon, 13 Jun 2011 05:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9RhkNJ6jAjU for ; Mon, 13 Jun 2011 05:59:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8694A1F0C44 for ; Mon, 13 Jun 2011 05:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=5370; q=dns/txt; s=iport; t=1307969994; x=1309179594; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rE04FXA7NVedIMkKiVnD9oFhCqUz4MqgCaYJO0tdXK8=; b=gEQw/T5mzslwsr3tm99DUWjG2/b8/kcTQI0wFynkC9dUnV0pfPV9sPnX q5Uh3vwMcInp3b0bfdLVNKsSzRF/0NPwqXGa8IllqZHYKCOqNnWruhPEY rAeeDNyl11y/zhYwAvxknfbyh8xHt2kkmm2sN9WhjQMibM/Q7iVw6H0DS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAFsI9k2tJXG8/2dsb2JhbABSl1KOZHeIcqF/nTqGJASHDY5/iyM X-IronPort-AV: E=Sophos;i="4.65,358,1304294400"; d="scan'208";a="712503635" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2011 12:59:54 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5DCxnVW023298; Mon, 13 Jun 2011 12:59:53 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 07:59:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 07:59:50 -0500 Message-ID: In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwi2YMzGEKrsYkCTqOR+0a/a2b14QEgKCViAHfPjsAAFqWMwQANDZlQ References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> From: "Bernie Volz (volz)" To: "Bharat Joshi" X-OriginalArrivalTime: 13 Jun 2011 12:59:53.0376 (UTC) FILETIME=[C9908A00:01CC29C9] Cc: dhcwg@ietf.org, "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:59:55 -0000 First, let me say that I'd MUCH prefer a type field over multiple suboptions if we feel there is likely to be a need for multiple identifiers. The reason is that with multiple suboptions, a relay would potentially need to send more than one (in case a server didn't support one of the newer suboptions) and it would be much more difficult to determine which to use / which was used (from the server's / relay's perspective). Second, a DUID is tied to a device (at least the default DUID) but there is nothing that says you can't configure a replacement device to use the same DUID as the previous device - though obviously you have to be careful to assure that the previous device no longer uses that DUID (either because it is discarded or because it is re-initialized and generates a new DUID, if DUID-LLT). Third, I think if you stick with an opaque identifier, you would need to be clear to add text that says something like a relay MUST NOT generate this identifier nor use it until it is ADMINISTRATIVELY configured and it is up to the administrator then to assure it is unique across the administrative domain. There is nothing in the draft that states this. Fourth, I think having a DUID based identifier is the best option for most cases. If you want the industrial Ethernet environment where you need something that is stable across devices, then add a type that allows this administratively configured identifier. But as a general relay identifier I would use the DUID. So, you might define: Type =3D 1 - DUID (default type) Type =3D 2 - Opaque identifier (must only be used if administratively configured on the device and requires administrator to assure it is unique). - Bernie -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com]=20 Sent: Monday, June 13, 2011 2:45 AM To: Bernie Volz (volz) Cc: Mark Stapp (mjs); dhcwg@ietf.org Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Hi Bernie, Thanks a lot for the quick review. Please see my response in line. Regards, Bharat >Hi ... I've decided to add the DHC WG as this is a document being worked > on there. Yes. No issues. > Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger > argument for this).=20 That make sense. I can surely do this in next revision. > And, I doubt the IESG will be happy with this document and leaving the > actual identifier as completely opaque! How would this identifying data > be assured to be unique if it is just defined as a 'series of octets'? The draft suggest that this opaque identifier be administratively configured and there should be a mean to display this to the administrator. So we expect administrator to be able to take care of keeping it unique in their own administrative domain. > I also fail to see why the DUID isn't being recommended as the standard > format for this relay identifier? See RFC 5460 section 5.4, > OPTION_RELAY_ID. The previous version of this draft had suggested the use of DUID. But we had to remove it because our use cases required that same relay-id be used even if the device is replaced. > And, thus do we really need a type field in the option? Isn't just a > DUID sufficient? That 'type' field was kept from the previous revision, for the future extensibility. At present, we feel that an opaque relay-id fulfils works for our use-cases but in future that may be other use-cases which might want to use a different type of relay-id. In fact, Ted and Pavan had a similar comments. If most of the people feel that we can define a new sub-option when such a requirements comes, we can remove this 'type' field. > I'd also say that for "compatibility" with DHCPv6, using the DUID as the > relay identifier too would be really convenient and appropriate. This > also means section 6 can probably be significantly scaled back - the > only issue is the unicast RENEW. I am not sure if using DUID for the use-cases mentioned in this draft will be appropriate.=20 We had to come out with this new revision because it was pointed out that DUID cannot be used where same id is required even when the devices are replaced. Once we decide upon whether we can use DUID or not, we can discuss other points which you have raised here. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely=20 for the use of the addressee(s). If you are not the intended recipient, please=20 notify the sender by e-mail and delete the original message. Further, you are not=20 to copy, disclose, or distribute this e-mail or its contents to any other person and=20 any such actions are unlawful. This e-mail may contain viruses. Infosys has taken=20 every reasonable precaution to minimize this risk, but is not liable for any damage=20 you may sustain as a result of any virus in this e-mail. You should carry out your=20 own virus checks before opening the e-mail or attachment. Infosys reserves the=20 right to monitor and review the content of all messages sent to or from this e-mail=20 address. Messages sent to or from this e-mail address may be stored on the=20 Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From mjs@cisco.com Mon Jun 13 06:38:53 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10559E800B for ; Mon, 13 Jun 2011 06:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+bR60oWTzdo for ; Mon, 13 Jun 2011 06:38:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id D0C489E8009 for ; Mon, 13 Jun 2011 06:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mjs@cisco.com; l=6802; q=dns/txt; s=iport; t=1307972332; x=1309181932; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kfUaG6NRtnUWmrA4IVaejaIkKoqoEY0vMRpaoNhE2Vo=; b=kJ2cyw4G8N0CNF8xKDojnSxQYrj0trIMnJP2nC8I7N3m9AFscqsoF4o1 OqrWN1a3yRF9xoK2tzhXyxa372hUw4uCkvRdmjGvYZO+GeahFBvv55SLt HkA67nDtlgNDWCQ0vJO2xq4Yu01moH+4y7veW0WYMvKCBX7Ru4mxKl28f o=; X-IronPort-AV: E=Sophos;i="4.65,358,1304294400"; d="scan'208";a="335846456" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2011 13:38:52 +0000 Received: from [161.44.71.239] ([161.44.71.239]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5DDcpt9003846; Mon, 13 Jun 2011 13:38:52 GMT Message-ID: <4DF612EB.2020804@cisco.com> Date: Mon, 13 Jun 2011 09:38:51 -0400 From: Mark Stapp User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:38:53 -0000 Hi Bernie, yes, I'd also prefer to use a single suboption for this purpose. on the issue of the use of DUID, there's a disagreement. I understood Ted to say that he objected very strongly to any text that proposed 'moving' a DUID from one device to another, or administratively managing DUIDs. I'll let Ted speak for himself, of course, but that's a fundamental issue for this draft. the brief history is: - initial draft just describes opaque identifier, offers two suggestions for assigning id: ascii string and DUID-generating algorithm - someone in WG discussion (David Hankins, maybe?) asked that there be a type-byte. type byte was added. - Ted realized that the draft was proposing to assign DUID generated as relay-id by one device to another device, and objected - Bharat re-issued draft sort of back at initial state, with just opaque id, and no implication that DUID was appropriate so the question is: can a DUID-based relay identifier be administered? if so, then we can return that suggestion to the draft. if not, we'll stick with 'opaque'. in either case, we'll add text to make it clear that the identifier needs to be administratively-unique. Thanks, Mark On 6/13/11 8:59 AM, Bernie Volz (volz) wrote: > First, let me say that I'd MUCH prefer a type field over multiple > suboptions if we feel there is likely to be a need for multiple > identifiers. The reason is that with multiple suboptions, a relay would > potentially need to send more than one (in case a server didn't support > one of the newer suboptions) and it would be much more difficult to > determine which to use / which was used (from the server's / relay's > perspective). > > Second, a DUID is tied to a device (at least the default DUID) but there > is nothing that says you can't configure a replacement device to use the > same DUID as the previous device - though obviously you have to be > careful to assure that the previous device no longer uses that DUID > (either because it is discarded or because it is re-initialized and > generates a new DUID, if DUID-LLT). > > Third, I think if you stick with an opaque identifier, you would need to > be clear to add text that says something like a relay MUST NOT generate > this identifier nor use it until it is ADMINISTRATIVELY configured and > it is up to the administrator then to assure it is unique across the > administrative domain. There is nothing in the draft that states this. > > Fourth, I think having a DUID based identifier is the best option for > most cases. If you want the industrial Ethernet environment where you > need something that is stable across devices, then add a type that > allows this administratively configured identifier. But as a general > relay identifier I would use the DUID. > > So, you might define: > Type = 1 - DUID (default type) > Type = 2 - Opaque identifier (must only be used if > administratively configured on the device and requires administrator to > assure it is unique). > > - Bernie > > -----Original Message----- > From: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Monday, June 13, 2011 2:45 AM > To: Bernie Volz (volz) > Cc: Mark Stapp (mjs); dhcwg@ietf.org > Subject: RE: [dhcwg] I-D Action: > draft-ietf-dhc-relay-id-suboption-08.txt > > Hi Bernie, > > Thanks a lot for the quick review. Please see my response in line. > > Regards, > Bharat > >> Hi ... I've decided to add the DHC WG as this is a document being > worked >> on there. > Yes. No issues. > >> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger >> argument for this). > That make sense. I can surely do this in next revision. > >> And, I doubt the IESG will be happy with this document and leaving the >> actual identifier as completely opaque! How would this identifying > data >> be assured to be unique if it is just defined as a 'series of octets'? > The draft suggest that this opaque identifier be administratively > configured and there should be a mean to display this to the > administrator. So we expect administrator to be able to take care of > keeping it unique in their own administrative domain. > >> I also fail to see why the DUID isn't being recommended as the > standard >> format for this relay identifier? See RFC 5460 section 5.4, >> OPTION_RELAY_ID. > The previous version of this draft had suggested the use of DUID. But we > had to remove it because our use cases required that same relay-id be > used even if the device is replaced. > >> And, thus do we really need a type field in the option? Isn't just a >> DUID sufficient? > That 'type' field was kept from the previous revision, for the future > extensibility. At present, we feel that an opaque relay-id fulfils works > for our use-cases but in future that may be other use-cases which might > want to use a different type of relay-id. > > In fact, Ted and Pavan had a similar comments. If most of the people > feel that we can define a new sub-option when such a requirements comes, > we can remove this 'type' field. > >> I'd also say that for "compatibility" with DHCPv6, using the DUID as > the >> relay identifier too would be really convenient and appropriate. This >> also means section 6 can probably be significantly scaled back - the >> only issue is the unicast RENEW. > I am not sure if using DUID for the use-cases mentioned in this draft > will be appropriate. > > We had to come out with this new revision because it was pointed out > that DUID cannot be used where same id is required even when the devices > are replaced. > > Once we decide upon whether we can use DUID or not, we can discuss other > points which you have raised here. > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, > you are not > to copy, disclose, or distribute this e-mail or its contents to any > other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys > has taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should > carry out your > own virus checks before opening the e-mail or attachment. Infosys > reserves the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on > the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > From volz@cisco.com Mon Jun 13 07:05:16 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1DA9E8014 for ; Mon, 13 Jun 2011 07:05:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR8vcf4T-oxo for ; Mon, 13 Jun 2011 07:05:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C7B4B9E8013 for ; Mon, 13 Jun 2011 07:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=9563; q=dns/txt; s=iport; t=1307973915; x=1309183515; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TXv7bjjjCo0T7Qu12dw+DLSTeC2XG1N8m+BcAghot90=; b=O9cB43gKehmcFUoh74IHOoIMdQLjoROXC4DwiG7f9feswLD3V9dR+LVL RPoUb3LFkafryrB6ItMVc+Uoa5HDq8/G9YqIixdOSq/UEgfZeKq0eQuS/ OPzKby2yLiYbZxIiAuLk986Zz0+VK/rx2Spj2ycbKiQvjKU0kwXArt8Es M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAKgY9k2tJXG8/2dsb2JhbABSl1OOZXeqXJ1BhiQEhw2Of4sj X-IronPort-AV: E=Sophos;i="4.65,358,1304294400"; d="scan'208";a="375539142" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2011 14:05:14 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5DE5Efp023110; Mon, 13 Jun 2011 14:05:14 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 09:05:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 09:05:12 -0500 Message-ID: In-Reply-To: <4DF612EB.2020804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwpzz3J1HGz4PM7S7ezz6IH4DAtbgAALcDQ References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> <4DF612EB.2020804@cisco.com> From: "Bernie Volz (volz)" To: "Mark Stapp (mjs)" X-OriginalArrivalTime: 13 Jun 2011 14:05:14.0716 (UTC) FILETIME=[EADD89C0:01CC29D2] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:05:16 -0000 >so the question is: can a DUID-based relay identifier be administered? if so,=20 >then we can return that suggestion to the draft. if not, we'll stick with=20 >'opaque'. in either case, we'll add text to make it clear that the identifier=20 >needs to be administratively-unique. Regarding the DUID, that is a complex issue and question. For a device with storage, if you moved the storage to another device, it would retain the DUID. So, the DUID is not really something that is hardwired in this case. Of course, this really only applies to DUID-LLT as that is the only type that needs to be stored. (The other types are generated from 'hardwired' data and thus need no storage.) I really don't see why you don't do both? The default identifier that can be used by any device 'out of the box' is the DUID type. Nothing has to be configured for the device to use this. If the administrator optionally configures an alternative 'opaque' identifier, then the device uses that instead - with the understanding that it is up to the administrator to assure that this identifier is unique. Hence, leave the type byte and have the two forms. You get both capabilities - an identifier that can be used without any configuration and an identifier that can be used in a case where a stable identifier across multiple potential "replacement" devices works. It is an interesting question as to whether we might want to think about a DUID-OI (Opaque Identifier) at some point to accommodate "locally administered" identifiers. These would NOT be allowed except when administratively configured with the understanding that the administrator must assure it is unique. This would then preclude the need for a type byte in this suboption and also be useable by DHCPv6 relay agents. One could even envision that part of the identifier might include a randomly generated value along the idea of the IPv6 Unique Local Addresses (ULA) [probably just use the ULA?] as that could avoid some issues when two administrative domains are collapsed into one. Perhaps a draft I should think about writing? (If this has merit, perhaps then your draft is simplified as all it needs to state is using the DUID.) The DUID-OI data format could be 6+ octets: - 6 octets of the 48-bit ULA value (see RFC 4193 - this includes 7-bit prefix (FC00::/7), L bit, and 40 bit Global ID.) - octets that follow which are the unique identifier. - Bernie -----Original Message----- From: Mark Stapp (mjs)=20 Sent: Monday, June 13, 2011 9:39 AM To: Bernie Volz (volz) Cc: Bharat Joshi; dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Hi Bernie, yes, I'd also prefer to use a single suboption for this purpose. on the issue of the use of DUID, there's a disagreement. I understood Ted to say=20 that he objected very strongly to any text that proposed 'moving' a DUID from=20 one device to another, or administratively managing DUIDs. I'll let Ted speak=20 for himself, of course, but that's a fundamental issue for this draft. the brief history is: - initial draft just describes opaque identifier, offers two suggestions for=20 assigning id: ascii string and DUID-generating algorithm - someone in WG discussion (David Hankins, maybe?) asked that there be a type-byte. type byte was added. - Ted realized that the draft was proposing to assign DUID generated as relay-id=20 by one device to another device, and objected - Bharat re-issued draft sort of back at initial state, with just opaque id, and=20 no implication that DUID was appropriate so the question is: can a DUID-based relay identifier be administered? if so,=20 then we can return that suggestion to the draft. if not, we'll stick with=20 'opaque'. in either case, we'll add text to make it clear that the identifier=20 needs to be administratively-unique. Thanks, Mark On 6/13/11 8:59 AM, Bernie Volz (volz) wrote: > First, let me say that I'd MUCH prefer a type field over multiple > suboptions if we feel there is likely to be a need for multiple > identifiers. The reason is that with multiple suboptions, a relay would > potentially need to send more than one (in case a server didn't support > one of the newer suboptions) and it would be much more difficult to > determine which to use / which was used (from the server's / relay's > perspective). > > Second, a DUID is tied to a device (at least the default DUID) but there > is nothing that says you can't configure a replacement device to use the > same DUID as the previous device - though obviously you have to be > careful to assure that the previous device no longer uses that DUID > (either because it is discarded or because it is re-initialized and > generates a new DUID, if DUID-LLT). > > Third, I think if you stick with an opaque identifier, you would need to > be clear to add text that says something like a relay MUST NOT generate > this identifier nor use it until it is ADMINISTRATIVELY configured and > it is up to the administrator then to assure it is unique across the > administrative domain. There is nothing in the draft that states this. > > Fourth, I think having a DUID based identifier is the best option for > most cases. If you want the industrial Ethernet environment where you > need something that is stable across devices, then add a type that > allows this administratively configured identifier. But as a general > relay identifier I would use the DUID. > > So, you might define: > Type =3D 1 - DUID (default type) > Type =3D 2 - Opaque identifier (must only be used if > administratively configured on the device and requires administrator to > assure it is unique). > > - Bernie > > -----Original Message----- > From: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Monday, June 13, 2011 2:45 AM > To: Bernie Volz (volz) > Cc: Mark Stapp (mjs); dhcwg@ietf.org > Subject: RE: [dhcwg] I-D Action: > draft-ietf-dhc-relay-id-suboption-08.txt > > Hi Bernie, > > Thanks a lot for the quick review. Please see my response in line. > > Regards, > Bharat > >> Hi ... I've decided to add the DHC WG as this is a document being > worked >> on there. > Yes. No issues. > >> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger >> argument for this). > That make sense. I can surely do this in next revision. > >> And, I doubt the IESG will be happy with this document and leaving the >> actual identifier as completely opaque! How would this identifying > data >> be assured to be unique if it is just defined as a 'series of octets'? > The draft suggest that this opaque identifier be administratively > configured and there should be a mean to display this to the > administrator. So we expect administrator to be able to take care of > keeping it unique in their own administrative domain. > >> I also fail to see why the DUID isn't being recommended as the > standard >> format for this relay identifier? See RFC 5460 section 5.4, >> OPTION_RELAY_ID. > The previous version of this draft had suggested the use of DUID. But we > had to remove it because our use cases required that same relay-id be > used even if the device is replaced. > >> And, thus do we really need a type field in the option? Isn't just a >> DUID sufficient? > That 'type' field was kept from the previous revision, for the future > extensibility. At present, we feel that an opaque relay-id fulfils works > for our use-cases but in future that may be other use-cases which might > want to use a different type of relay-id. > > In fact, Ted and Pavan had a similar comments. If most of the people > feel that we can define a new sub-option when such a requirements comes, > we can remove this 'type' field. > >> I'd also say that for "compatibility" with DHCPv6, using the DUID as > the >> relay identifier too would be really convenient and appropriate. This >> also means section 6 can probably be significantly scaled back - the >> only issue is the unicast RENEW. > I am not sure if using DUID for the use-cases mentioned in this draft > will be appropriate. > > We had to come out with this new revision because it was pointed out > that DUID cannot be used where same id is required even when the devices > are replaced. > > Once we decide upon whether we can use DUID or not, we can discuss other > points which you have raised here. > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, > you are not > to copy, disclose, or distribute this e-mail or its contents to any > other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys > has taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should > carry out your > own virus checks before opening the e-mail or attachment. Infosys > reserves the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on > the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > From iesg-secretary@ietf.org Mon Jun 13 09:43:17 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C711E809E; Mon, 13 Jun 2011 09:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTtyYE7RATdS; Mon, 13 Jun 2011 09:43:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1746D9E8013; Mon, 13 Jun 2011 09:43:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110613164317.9856.19420.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 09:43:17 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)' to Proposed Standard (draft-ietf-dhc-duid-uuid-03.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:43:18 -0000 The IESG has approved the following document: - 'Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)' (draft-ietf-dhc-duid-uuid-03.txt) as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-duid-uuid/ Technical Summary This document defines a new DHCP Unique Identifier (DUID) type to be used for identifying clients using Universally Unique Identifiers (UUIDs). The document defines what is meant by "universal," excluding several things called UUIDs that do not qualify. The purpose of the document is to allow devices that have genuine UUIDs to use those as DUIDs, rather than forming new identifiers and requiring the maintenance of tables mapping between UUIDs and DUIDs. Working Group Summary This document appeared in the working group in October of 2010. There has been substantial review of this document. Document Quality The document has undergone careful review, and the working group is satisfied with its quality. Personnel The document shepherd is Ted Lemon . The responsible Area Director is Ralph Droms . From Ted.Lemon@nominum.com Mon Jun 13 10:33:59 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F611E8157 for ; Mon, 13 Jun 2011 10:33: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+NTnb3NjoWG for ; Mon, 13 Jun 2011 10:33:58 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0911E8153 for ; Mon, 13 Jun 2011 10:33:57 -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 DSNKTfZKBBz4Sa+WDaZs8jvP4Dbm/svfkgpv@postini.com; Mon, 13 Jun 2011 10:33:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9807B1B8516 for ; Mon, 13 Jun 2011 10:33:56 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8BDF5190052; Mon, 13 Jun 2011 10:33:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from kali.ddns.nominum.com (64.89.225.6) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 13 Jun 2011 10:33:56 -0700 MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4DF612EB.2020804@cisco.com> Date: Mon, 13 Jun 2011 10:33:55 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <4C417865-F005-4D79-AC44-B87FD5200AD7@nominum.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> <4DF612EB.2020804@cisco.com> To: Mark Stapp X-Mailer: Apple Mail (2.1237.1) Cc: dhcwg@ietf.org, "Bernie Volz \(volz\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:33:59 -0000 On Jun 13, 2011, at 6:38 AM, Mark Stapp wrote: > on the issue of the use of DUID, there's a disagreement. I understood = Ted to say that he objected very strongly to any text that proposed = 'moving' a DUID from one device to another, or administratively managing = DUIDs. I'll let Ted speak for himself, of course, but that's a = fundamental issue for this draft. No, what I objected to was moving unique identifiers from device to = device. If you have a unique identifier, it identifies a device. If = you start moving it around, it loses that property. The right way to = use unique identifiers is to have a mapping between the identifier and = whatever role it is that you want to assign to the thing that has been = uniquely identified. What you proposed, which I didn't particularly like, was simply putting = the role identifier on the device. The only reason I didn't like it is = that it means we need to define some other identifier that's a unique = identifier. Perhaps a better way to put it is that I thought you were = trying to uniquely identify the device, but it later turned out that = that was not the case--you merely wanted to identify its role. I still think it's better to uniquely identify the device, and have a = central map between device identity and role. But I agreed with you = that if you really intended the semantics of the option to be that = identifies the role of the device, and not the device, I would be okay = with that. However, if the identifier is a role identifier, and not a unique = identifier, then you shouldn't use the term "UUID" to describe it, nor = should you put a UUID in it, because in doing so you turn the UUID into = a non-unique identifier. And you shouldn't use a DUID, because a DUID = is essentially a DHCP-specific UUID. So yes, I object very strongly to defining an identifier that is = "unique" but also might be transferred from device to device. If you = take away the uniqueness, I think what you're left with isn't useful to = me, but I don't object to you defining it if it's useful to you. I would also say that this is another reason why this ought not to be an = option with a "type" field. The option as Mark was defining it was = going to have a very constrained function. It wasn't going to be a = unique identifier. So the idea that it would be extended to support = new identifier types in the future doesn't make a whole lot of sense to = me. From Ted.Lemon@nominum.com Mon Jun 13 10:34:17 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEEC11E8176 for ; Mon, 13 Jun 2011 10:34: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K+7q1OvDLa0 for ; Mon, 13 Jun 2011 10:34:17 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E011E8177 for ; Mon, 13 Jun 2011 10:34:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTfZKGEpaKTa/kcxaNUXRkOoFKvY2XhEI@postini.com; Mon, 13 Jun 2011 10:34: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 EEFE11B8514 for ; Mon, 13 Jun 2011 10:34:15 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E799F190052; Mon, 13 Jun 2011 10:34:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from kali.ddns.nominum.com (64.89.225.6) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 13 Jun 2011 10:34:15 -0700 MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Mon, 13 Jun 2011 10:34:15 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F15@BLRKECMBX02.ad.infosys.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1B@BLRKECMBX02.ad.infosys.com> <9B800A80-B90E-47DF-91B7-19DECBC32A5E@nominum.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F1D@BLRKECMBX02.ad.infosys.com> <243EA4AA-9165-4BC5-BE81-50E219A5F35E@nominum.com> To: Leaf yeh X-Mailer: Apple Mail (2.1237.1) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:34:17 -0000 On Jun 8, 2011, at 7:29 PM, Leaf yeh wrote: > Supposed you're talking about the space shortage of the DHCPv4 option = codes. Yes, sorry, I have IPv6 on the brain at the moment, and forgot that we = were talking about a DHCPv4 option. From tomasz.mrugalski@gmail.com Mon Jun 13 13:28:37 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D546611E8109 for ; Mon, 13 Jun 2011 13:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa+uYiOC5VTg for ; Mon, 13 Jun 2011 13:28:37 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEA11E8107 for ; Mon, 13 Jun 2011 13:28:36 -0700 (PDT) Received: by eye13 with SMTP id 13so2168561eye.31 for ; Mon, 13 Jun 2011 13:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=XEQC0QfIDLpULi3cUYkSaso5/v8jBVND5upWcbSqkYM=; b=UUrmJF2HM4r5fYQK5uPYOjqpK3RzuAW/zueObYfmdu1bdOKbektTHCzXnkny16jc5A 4bSNs4uKPBdNG/j74IST7GVr3ENIxTo1kIBPT1knLz3JKpRZnlUP61nJh4A3MCXsIgAp ZTiWRLXk2keBYODRLjll/MzzmMARqRFM82k/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; b=efVY8eUCpdoduNNynCXUvgrLcXuq7j7iNjcaWOofxl3Zuom9YvCbToBD7Xw7ofzrCK kp2wNeDl82w0aIngOYhAFe5KBd0wugmmiK8XcfRuNl2xAutxzY1zmfb1+LIsj95s23lT XwQ9afgTRaYNtxE/KTM0QKlnvqqoqps/6l6LM= Received: by 10.14.100.194 with SMTP id z42mr2553526eef.108.1307996915462; Mon, 13 Jun 2011 13:28:35 -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 g48sm5507290eea.26.2011.06.13.13.28.33 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 13:28:34 -0700 (PDT) Message-ID: <4DF672F0.4020106@gmail.com> Date: Mon, 13 Jun 2011 22:28:32 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4DED48F8.4050705@gmail.com> In-Reply-To: <4DED48F8.4050705@gmail.com> X-TagToolbar-Keys: D20110613222832437 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Failover 2011-06-13 meeting minutes, 2011-06-20 meeting invitation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 20:28:38 -0000 Here are the minutes from second DHCPv6 failover requirements meeting. Bridge info was sent to anyone who responded to my request for participation or otherwise expressed interest. The next meeting is scheduled for: Monday, 2011-06-20 10:00 PDT (19:00 CEST) I would like to point out that this is pre-IETF activity. Failover requirements draft will be published in less than 2 weeks and will follow the usual IETF way. Due to privacy concerns, the audio bridge number for the next meeting is not going to be announced on mailing list. I will send bridge numbers and/or current draft version to anyone who asks, though. Bridge details and draft was sent to 18 interested folks before today's meeting. It seems that there is general agreement regarding the shape of requirements document. Discussion is trending towards initial design aspects - something that will eventually become v6 failover design document. Tomek ------- Failover requirements - June 13 2011 10:00 am PDT (19:00 CEST) Attendees - Greg Gabil (Jager Net Technologies) - Kim Kinnear (Cisco) - Suresh Krishnan (Ericsson) - Tomasz Mrugalski (ISC) - Shawn Routher (ISC) 1. Agenda bashing No additional agenda items 2. Summary of latest changes to requirements specification - Added clarification that "2 peers" means a pair (2 servers in total, not 2 backup servers + primary) - Added requirement that failover must not impact performance too much (i.e. lazy updates should be used) - added description of failure modes (server-down and network partition) - added description of possible synchronization modes (lockstep vs lazy updates) - Added requirement that protocol must be able to recover from server-down event - Added requirement that protocol should be able to recover from network-partition event - Added section about failure modes (server down vs network partition) - Added section about failover alternatives. It documents scenarios, where failover is not really needed - Removed referenced to VRRP as suggested by Frank Sweetser and Kim Kinnear - Removed random questions section - Added a clarification that 1-to-1 is the only scenario that is covered by the failover scenario. Also added a note that m-to-1 may be achieved as multiple instances of 1-to-1, but such cases are considered deployment scenarios and are irrelevant from the protocol point of view. - Cleared up a misconception that failover can be used as load balancing "for free". As each partner must be able to handle the full traffic in case of partner-down event, there's no real benefit in using failover for LB purposes. 3. Topics proposed by Kim - Lease database sync - TCP or UDP? Probably TCP - no discussion - Transmission of information. Should it go to design or protocol document? Should it be based on bulk leasequery? BLQ with changes? Something else? This is being deferred to the design discussion. Discussion of what should be in the requirements document. In particular should we include non-goals such as n-1 in the text. We all seem to be agreeing that we want a simple solution we seem to be having some question as to what to say and how to say it in the document. Should we allow or prohibit n-1 relationship. There is a push to limit ourselves to 1-1 with each peer in only one relationship. This is based on some experience with the complications that arise from trying to allow one peer to be in multiple relationships. A suggestion is to leave this as a potential extension, the base document would only support 1-1 with one relationship while an extension could be written to allow for multiple relationships. - conflict resolution algorithm - how to decide which data is "best"? Time? Sequence numbers? This is being deferred to the design discussion. - MCLT - maximum client lead time (a concept used in v4 failover) This is being deferred to the design discussion. - Lazy update - frequency Some discussion about frequency and latency. We seem to be in general agreement that we need something like lazy update in order to minimize impact on the performance of the server. We won't have a requirement to batch any specific number of requests though batching is a likely implementation strategy. 4. Next steps - What should we do for our next steps. Should we start working on the design document or should we wait for feedback from the working group either on the email list or at the Quebec City. There's some thought to wait until we get feedback but mostly it sounds like we can and should start working on the design as we have time and energy. - Previously we had heard that cross-vendor interoperability was not really necessary. We have one person that feels that this is a requirement. Determining if this is a true end-user requirement will be good. From greg.rabil@jagornet.com Mon Jun 13 13:34:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE811E810E for ; Mon, 13 Jun 2011 13:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S852t6dw7aDp for ; Mon, 13 Jun 2011 13:34:24 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id CA0F8228017 for ; Mon, 13 Jun 2011 13:34:23 -0700 (PDT) Received: by pxi20 with SMTP id 20so3635114pxi.27 for ; Mon, 13 Jun 2011 13:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.69.43 with SMTP id b11mr2602416pbu.104.1307997260373; Mon, 13 Jun 2011 13:34:20 -0700 (PDT) Received: by 10.68.56.230 with HTTP; Mon, 13 Jun 2011 13:34:20 -0700 (PDT) In-Reply-To: <4DF672F0.4020106@gmail.com> References: <4DED48F8.4050705@gmail.com> <4DF672F0.4020106@gmail.com> Date: Mon, 13 Jun 2011 16:34:20 -0400 Message-ID: From: "A. Gregory Rabil" To: Tomasz Mrugalski Content-Type: multipart/alternative; boundary=000e0cd209f012611104a59dd8ee Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Failover 2011-06-13 meeting minutes, 2011-06-20 meeting invitation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 20:34:25 -0000 --000e0cd209f012611104a59dd8ee Content-Type: text/plain; charset=ISO-8859-1 Hi Tomek, Please update your minutes for my contact info as an attendee: Greg Rabil - Jagornet Technologies Many thanks, Greg On Mon, Jun 13, 2011 at 4:28 PM, Tomasz Mrugalski < tomasz.mrugalski@gmail.com> wrote: > Here are the minutes from second DHCPv6 failover requirements meeting. > > Bridge info was sent to anyone who responded to my request for > participation or otherwise expressed interest. The next meeting is > scheduled for: > > Monday, 2011-06-20 10:00 PDT (19:00 CEST) > > I would like to point out that this is pre-IETF activity. Failover > requirements draft will be published in less than 2 weeks and will > follow the usual IETF way. > > Due to privacy concerns, the audio bridge number for the next meeting is > not going to be announced on mailing list. I will send bridge numbers > and/or current draft version to anyone who asks, though. Bridge details > and draft was sent to 18 interested folks before today's meeting. > > It seems that there is general agreement regarding the shape of > requirements document. Discussion is trending towards initial design > aspects - something that will eventually become v6 failover design > document. > > Tomek > > ------- > > Failover requirements - June 13 2011 > 10:00 am PDT (19:00 CEST) > > Attendees > - Greg Gabil (Jager Net Technologies) > - Kim Kinnear (Cisco) > - Suresh Krishnan (Ericsson) > - Tomasz Mrugalski (ISC) > - Shawn Routher (ISC) > > 1. Agenda bashing > No additional agenda items > > 2. Summary of latest changes to requirements specification > > - Added clarification that "2 peers" means a pair (2 servers in total, > not 2 backup servers + primary) > - Added requirement that failover must not impact performance too much > (i.e. lazy updates should be used) > - added description of failure modes (server-down and network partition) > - added description of possible synchronization modes (lockstep > vs lazy updates) > - Added requirement that protocol must be able to recover from > server-down event > - Added requirement that protocol should be able to recover from > network-partition event > > - Added section about failure modes (server down vs network partition) > > - Added section about failover alternatives. It documents scenarios, > where failover is not really needed > > - Removed referenced to VRRP as suggested by Frank Sweetser and Kim Kinnear > > - Removed random questions section > > - Added a clarification that 1-to-1 is the only scenario that is > covered by the failover scenario. Also added a note that m-to-1 may > be achieved as multiple instances of 1-to-1, but such cases are > considered deployment scenarios and are irrelevant from the protocol > point of view. > > - Cleared up a misconception that failover can be used as load > balancing "for free". As each partner must be able to handle the full > traffic in case of partner-down event, there's no real benefit in > using failover for LB purposes. > > 3. Topics proposed by Kim > > - Lease database sync - TCP or UDP? > Probably TCP - no discussion > > - Transmission of information. Should it go to design or protocol > document? Should it be based on bulk leasequery? BLQ with changes? > Something else? > This is being deferred to the design discussion. > > Discussion of what should be in the requirements document. In > particular should we include non-goals such as n-1 in the text. > We all seem to be agreeing that we want a simple solution we > seem to be having some question as to what to say and how to > say it in the document. > > Should we allow or prohibit n-1 relationship. There is a > push to limit ourselves to 1-1 with each peer in only one > relationship. This is based on some experience with the > complications that arise from trying to allow one peer to > be in multiple relationships. A suggestion is to leave this > as a potential extension, the base document would only support > 1-1 with one relationship while an extension could be written > to allow for multiple relationships. > > - conflict resolution algorithm - how to decide which data is > "best"? Time? Sequence numbers? > This is being deferred to the design discussion. > > - MCLT - maximum client lead time (a concept used in v4 failover) > This is being deferred to the design discussion. > > - Lazy update - frequency > Some discussion about frequency and latency. We seem to be > in general agreement that we need something like lazy update > in order to minimize impact on the performance of the server. > We won't have a requirement to batch any specific number of > requests though batching is a likely implementation strategy. > > 4. Next steps > - What should we do for our next steps. Should we start working > on the design document or should we wait for feedback from the > working group either on the email list or at the Quebec City. > There's some thought to wait until we get feedback but mostly > it sounds like we can and should start working on the design > as we have time and energy. > > - Previously we had heard that cross-vendor interoperability was > not really necessary. We have one person that feels that this > is a requirement. Determining if this is a true end-user > requirement will be good. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --000e0cd209f012611104a59dd8ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tomek,
Please update your minutes for my contact info as an attendee= :

Greg Rabil - Jagornet Technologies
Many thanks,
Greg

On Mon, Jun 13, 2011 at 4:28 PM, Tomasz Mrugalski <tomasz.mrugalski@gmail.com&g= t; wrote:
Here are the minutes from second DHCPv6 failover requirements meeting.

Bridge info was sent to anyone who responded to my request for
participation or otherwise expressed interest. The next meeting is
scheduled for:

Monday, 2011-06-20 10:00 PDT (19:00 CEST)

I would like to point out that this is pre-IETF activity. Failover
requirements draft will be published in less than 2 weeks and will
follow the usual IETF way.

Due to privacy concerns, the audio bridge number for the next meeting is not going to be announced on mailing list. I will send bridge numbers
and/or current draft version to anyone who asks, though. Bridge details
and draft was sent to 18 interested folks before today's meeting.

It seems that there is general agreement regarding the shape of
requirements document. Discussion is trending towards initial design
aspects - something that will eventually become v6 failover design document= .

Tomek

-------

Failover requirements - June 13 2011
10:00 am PDT (19:00 CEST)

Attendees
- Greg Gabil (Jager Net Technologies)
- Kim Kinnear (Cisco)
- Suresh Krishnan (Ericsson)
- Tomasz Mrugalski (ISC)
- Shawn Routher (ISC)

1. Agenda bashing
No additional agenda items

2. Summary of latest changes to requirements specification

- Added clarification that "2 peers" means a pair (2 servers in t= otal,
=A0not 2 backup servers + primary)
- Added requirement that failover must not impact performance too much
=A0(i.e. lazy updates should be used)
- added description of failure modes (server-down and network partition) - added description of possible synchronization modes (lockstep
=A0vs lazy updates)
- Added requirement that protocol must be able to recover from
=A0server-down event
- Added requirement that protocol should be able to recover from
=A0network-partition event

- Added section about failure modes (server down vs network partition)

- Added section about failover alternatives. It documents scenarios,
=A0where failover is not really needed

- Removed referenced to VRRP as suggested by Frank Sweetser and Kim Kinnear=

- Removed random questions section

- Added a clarification that 1-to-1 is the only scenario that is
=A0covered by the failover scenario. Also added a note that m-to-1 may
=A0be achieved as multiple instances of 1-to-1, but such cases are
=A0considered deployment scenarios and are irrelevant from the protocol =A0point of view.

- Cleared up a misconception that failover can be used as load
=A0balancing "for free". As each partner must be able to handle = the full
=A0traffic in case of partner-down event, there's no real benefit in =A0using failover for LB purposes.

3. Topics proposed by Kim

- Lease database sync - TCP or UDP?
=A0Probably TCP - no discussion

- Transmission of information. Should it go to design or protocol
=A0document? Should it be based on bulk leasequery? BLQ with changes?
=A0Something else?
=A0 =A0This is being deferred to the design discussion.

Discussion of what should be in the requirements document. =A0In
particular should we include non-goals such as n-1 in the text.
We all seem to be agreeing that we want a simple solution we
seem to be having some question as to what to say and how to
say it in the document.

Should we allow or prohibit n-1 relationship. =A0There is a
push to limit ourselves to 1-1 with each peer in only one
relationship. =A0This is based on some experience with the
complications that arise from trying to allow one peer to
be in multiple relationships. =A0A suggestion is to leave this
as a potential extension, the base document would only support
1-1 with one relationship while an extension could be written
to allow for multiple relationships.

- conflict resolution algorithm - how to decide which data is
=A0"best"? Time? Sequence numbers?
=A0 =A0This is being deferred to the design discussion.

- MCLT - maximum client lead time (a concept used in v4 failover)
=A0 =A0This is being deferred to the design discussion.

- Lazy update - frequency
=A0 Some discussion about frequency and latency. =A0We seem to be
=A0 in general agreement that we need something like lazy update
=A0 in order to minimize impact on the performance of the server.
=A0 We won't have a requirement to batch any specific number of
=A0 requests though batching is a likely implementation strategy.

4. Next steps
- What should we do for our next steps. =A0Should we start working
=A0on the design document or should we wait for feedback from the
=A0working group either on the email list or at the Quebec City.
=A0There's some thought to wait until we get feedback but mostly
=A0it sounds like we can and should start working on the design
=A0as we have time and energy.

- Previously we had heard that cross-vendor interoperability was
=A0not really necessary. =A0We have one person that feels that this
=A0is a requirement. =A0Determining if this is a true end-user
=A0requirement will be good.


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

--000e0cd209f012611104a59dd8ee-- From bharat_joshi@infosys.com Tue Jun 14 09:46:11 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118BE11E814D for ; Tue, 14 Jun 2011 09:46:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO64k8+tBb0X for ; Tue, 14 Jun 2011 09:46:10 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 114E811E8146 for ; Tue, 14 Jun 2011 09:46:08 -0700 (PDT) X-TM-IMSS-Message-ID: <35de4d6200243b85@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 35de4d6200243b85 ; Tue, 14 Jun 2011 22:09:08 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub01.ad.infosys.com ([10.66.236.41]) with mapi; Tue, 14 Jun 2011 22:16:04 +0530 From: Bharat Joshi To: "Bernie Volz (volz)" , "Mark Stapp (mjs)" Date: Tue, 14 Jun 2011 22:16:04 +0530 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwpzz3J1HGz4PM7S7ezz6IH4DAtbgAALcDQADhMI2k= Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F36@BLRKECMBX02.ad.infosys.com> References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> <4DF612EB.2020804@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:46:11 -0000 Bernie, >so the question is: can a DUID-based relay identifier be administered? > if so,=20 > >then we can return that suggestion to the draft. if not, we'll stick > with=20 > >'opaque'. in either case, we'll add text to make it clear that the > identifier=20 > >needs to be administratively-unique. >=20 > Regarding the DUID, that is a complex issue and question. For a device > with storage, if you moved the storage to another device, it would > retain the DUID. So, the DUID is not really something that is hardwired > in this case. Of course, this really only applies to DUID-LLT as that is > the only type that needs to be stored. (The other types are generated > from 'hardwired' data and thus need no storage.) >=20 >=20 > I really don't see why you don't do both? Actually we end up removing DUID from the draft because we could not find a= use-case for DUID as relay-id. The two use-cases in this draft needs an administratively configured relay-= id. Can you think of any scenario where a DUID relay-id could be useful? > The default identifier that can be used by any device 'out of the box' > is the DUID type. Nothing has to be configured for the device to use > this. >=20 > If the administrator optionally configures an alternative 'opaque' > identifier, then the device uses that instead - with the understanding > that it is up to the administrator to assure that this identifier is > unique. >=20 > Hence, leave the type byte and have the two forms. You get both > capabilities - an identifier that can be used without any configuration > and an identifier that can be used in a case where a stable identifier > across multiple potential "replacement" devices works. The 'type' field came from previous revisions. I think we had unfortunately= assumed that DHCP server may parse/interpret the relay-id and so this type= field was kept here to indicate what kind of relay-id this sub-option is c= arrying. After looking at the use cases again, we think we can remove it as DHCP ser= ver would never need to parse/interpret it and relay-agent will always know= what it has used in relay-id sub-option. Let me know what you think? >=20 > It is an interesting question as to whether we might want to think about > a DUID-OI (Opaque Identifier) at some point to accommodate "locally > administered" identifiers. These would NOT be allowed except when > administratively configured with the understanding that the > administrator must assure it is unique. This would then preclude the > need for a type byte in this suboption and also be useable by DHCPv6 > relay agents. One could even envision that part of the identifier might > include a randomly generated value along the idea of the IPv6 Unique > Local Addresses (ULA) [probably just use the ULA?] as that could avoid > some issues when two administrative domains are collapsed into one. > Perhaps a draft I should think about writing? (If this has merit, > perhaps then your draft is simplified as all it needs to state is using > the DUID.) Yes. I agree. This might be useful. Some time back I think Mark and I were = discussing whether we need an administratively configured DUID which can be= reused. Thanks, Bharat > The DUID-OI data format could be 6+ octets: > - 6 octets of the 48-bit ULA value (see RFC 4193 - this includes 7-bit > prefix (FC00::/7), L bit, and 40 bit Global ID.) > - octets that follow which are the unique identifier. >=20 > - Bernie >=20 __ -----Original Message----- From: Mark Stapp (mjs) Sent: Monday, June 13, 2011 9:39 AM To: Bernie Volz (volz) Cc: Bharat Joshi; dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Hi Bernie, yes, I'd also prefer to use a single suboption for this purpose. on the issue of the use of DUID, there's a disagreement. I understood Ted to say that he objected very strongly to any text that proposed 'moving' a DUID from one device to another, or administratively managing DUIDs. I'll let Ted speak for himself, of course, but that's a fundamental issue for this draft. the brief history is: - initial draft just describes opaque identifier, offers two suggestions for assigning id: ascii string and DUID-generating algorithm - someone in WG discussion (David Hankins, maybe?) asked that there be a type-byte. type byte was added. - Ted realized that the draft was proposing to assign DUID generated as relay-id by one device to another device, and objected - Bharat re-issued draft sort of back at initial state, with just opaque id, and no implication that DUID was appropriate so the question is: can a DUID-based relay identifier be administered? if so, then we can return that suggestion to the draft. if not, we'll stick with 'opaque'. in either case, we'll add text to make it clear that the identifier needs to be administratively-unique. Thanks, Mark On 6/13/11 8:59 AM, Bernie Volz (volz) wrote: > First, let me say that I'd MUCH prefer a type field over multiple > suboptions if we feel there is likely to be a need for multiple > identifiers. The reason is that with multiple suboptions, a relay would > potentially need to send more than one (in case a server didn't support > one of the newer suboptions) and it would be much more difficult to > determine which to use / which was used (from the server's / relay's > perspective). > > Second, a DUID is tied to a device (at least the default DUID) but there > is nothing that says you can't configure a replacement device to use the > same DUID as the previous device - though obviously you have to be > careful to assure that the previous device no longer uses that DUID > (either because it is discarded or because it is re-initialized and > generates a new DUID, if DUID-LLT). > > Third, I think if you stick with an opaque identifier, you would need to > be clear to add text that says something like a relay MUST NOT generate > this identifier nor use it until it is ADMINISTRATIVELY configured and > it is up to the administrator then to assure it is unique across the > administrative domain. There is nothing in the draft that states this. > > Fourth, I think having a DUID based identifier is the best option for > most cases. If you want the industrial Ethernet environment where you > need something that is stable across devices, then add a type that > allows this administratively configured identifier. But as a general > relay identifier I would use the DUID. > > So, you might define: > Type =3D 1 - DUID (default type) > Type =3D 2 - Opaque identifier (must only be used if > administratively configured on the device and requires administrator to > assure it is unique). > > - Bernie > > -----Original Message----- > From: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Monday, June 13, 2011 2:45 AM > To: Bernie Volz (volz) > Cc: Mark Stapp (mjs); dhcwg@ietf.org > Subject: RE: [dhcwg] I-D Action: > draft-ietf-dhc-relay-id-suboption-08.txt > > Hi Bernie, > > Thanks a lot for the quick review. Please see my response in line. > > Regards, > Bharat > >> Hi ... I've decided to add the DHC WG as this is a document being > worked >> on there. > Yes. No issues. > >> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger >> argument for this). > That make sense. I can surely do this in next revision. > >> And, I doubt the IESG will be happy with this document and leaving the >> actual identifier as completely opaque! How would this identifying > data >> be assured to be unique if it is just defined as a 'series of octets'? > The draft suggest that this opaque identifier be administratively > configured and there should be a mean to display this to the > administrator. So we expect administrator to be able to take care of > keeping it unique in their own administrative domain. > >> I also fail to see why the DUID isn't being recommended as the > standard >> format for this relay identifier? See RFC 5460 section 5.4, >> OPTION_RELAY_ID. > The previous version of this draft had suggested the use of DUID. But we > had to remove it because our use cases required that same relay-id be > used even if the device is replaced. > >> And, thus do we really need a type field in the option? Isn't just a >> DUID sufficient? > That 'type' field was kept from the previous revision, for the future > extensibility. At present, we feel that an opaque relay-id fulfils works > for our use-cases but in future that may be other use-cases which might > want to use a different type of relay-id. > > In fact, Ted and Pavan had a similar comments. If most of the people > feel that we can define a new sub-option when such a requirements comes, > we can remove this 'type' field. > >> I'd also say that for "compatibility" with DHCPv6, using the DUID as > the >> relay identifier too would be really convenient and appropriate. This >> also means section 6 can probably be significantly scaled back - the >> only issue is the unicast RENEW. > I am not sure if using DUID for the use-cases mentioned in this draft > will be appropriate. > > We had to come out with this new revision because it was pointed out > that DUID cannot be used where same id is required even when the devices > are replaced. > > Once we decide upon whether we can use DUID or not, we can discuss other > points which you have raised here. > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, > you are not > to copy, disclose, or distribute this e-mail or its contents to any > other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys > has taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should > carry out your > own virus checks before opening the e-mail or attachment. Infosys > reserves the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on > the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > From mjs@cisco.com Tue Jun 14 10:41:32 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA3F11E819C for ; Tue, 14 Jun 2011 10:41:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-xeRTNfau8M for ; Tue, 14 Jun 2011 10:41:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 813A811E8196 for ; Tue, 14 Jun 2011 10:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mjs@cisco.com; l=1546; q=dns/txt; s=iport; t=1308073291; x=1309282891; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/iEBObPguByIY2SAl2ExOg/ZK1fSx5VAHmwUO6Z7Fpg=; b=lXFbaD89Can23RbXSW1cfm0FgmXUHLr9SrdBzHIsDajcCo+j2wq8pi+h prHvxgw25V9g7wa3EwKlbR/s7v6/Jiwj3ifaelHmB57G/XRFHR0n8bwPU RU3LPtsGtsAoAMnP1OMdmtnETuqjWKsHumt8t+QVbCUOXEpl70qT0HoBs I=; X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="93935604" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2011 17:41:27 +0000 Received: from [161.44.71.239] ([161.44.71.239]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5EHfQWY017485; Tue, 14 Jun 2011 17:41:26 GMT Message-ID: <4DF79D46.9040309@cisco.com> Date: Tue, 14 Jun 2011 13:41:26 -0400 From: Mark Stapp User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bharat Joshi References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> <4DF612EB.2020804@cisco.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F36@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F36@BLRKECMBX02.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 17:41:32 -0000 Bharat, I originally introduced the reference to DUID to address a need that did seem real to me. it seemed reasonable to describe a couple of ways an admin might come up with an identifier. one possibility was "make one up - use a string that means something to you in your network." another possibility was "ask the device to generate an id that's got a really good chance of being robust and unique." I pointed to the DUID-generating algorithm as an example. I do think it would/will be helpful if a device acting as a relay were willing to generate a relay-id. but I don't think that's an interoperability issue - it can always be a vendor value-add. all that's necessary is that the ids be administratively unique. -- Mark On 6/14/11 12:46 PM, Bharat Joshi wrote: >> Regarding the DUID, that is a complex issue and question. For a device >> with storage, if you moved the storage to another device, it would >> retain the DUID. So, the DUID is not really something that is hardwired >> in this case. Of course, this really only applies to DUID-LLT as that is >> the only type that needs to be stored. (The other types are generated >> from 'hardwired' data and thus need no storage.) >> >> >> I really don't see why you don't do both? > Actually we end up removing DUID from the draft because we could not find a use-case for DUID as relay-id. > > The two use-cases in this draft needs an administratively configured relay-id. > > Can you think of any scenario where a DUID relay-id could be useful? From volz@cisco.com Tue Jun 14 11:03:21 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7311E8078 for ; Tue, 14 Jun 2011 11:03: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMpQxVjn1Sfe for ; Tue, 14 Jun 2011 11:03:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id A204E21F848A for ; Tue, 14 Jun 2011 11:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=10974; q=dns/txt; s=iport; t=1308074600; x=1309284200; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=FXZhoT9ukKtFaOyPtOv6nAcyVYNRj4t4j99jtS5ea08=; b=No8D4UvVGYVQSvOK6f3Z+BUS7+kA+bq4dj/R0pLiBrN4RxkgLelJ+B3k 1Rl5aYPgClnW2YXQUpwincvxFYhopUN771p9Tww2aN1ETyzM5VOfn7Fjk BZ5tetlBP5MT03xUW44Drp+Y4AH/aCIVfZBit/MCsExNMiiGHUUNnIpcY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAD+h902tJXG9/2dsb2JhbABSl0yPB3eIc6IRnk6GJASHFY8TiyU X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="376493134" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2011 18:03:20 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5EI3JWm002429; Tue, 14 Jun 2011 18:03:19 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 13:03:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2011 13:03:18 -0500 Message-ID: In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9F36@BLRKECMBX02.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Thread-Index: Acwpzz3J1HGz4PM7S7ezz6IH4DAtbgAALcDQADhMI2kAAs+qMA== References: <20110604170424.3363.68771.idtracker@ietfa.amsl.com> <31D55C4D55BEED48A4459EB64567589A115E3C9F2B@BLRKECMBX02.ad.infosys.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F31@BLRKECMBX02.ad.infosys.com> <4DF612EB.2020804@cisco.com>, <31D55C4D55BEED48A4459EB64567589A115E3C9F36@BLRKECMBX02.ad.infosys.com> From: "Bernie Volz (volz)" To: "Bharat Joshi" , "Mark Stapp (mjs)" X-OriginalArrivalTime: 14 Jun 2011 18:03:19.0175 (UTC) FILETIME=[577AC170:01CC2ABD] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:03:21 -0000 I do think that we've discussed this to bits and it really is up to you how you want to proceed. - Bernie -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com]=20 Sent: Tuesday, June 14, 2011 12:46 PM To: Bernie Volz (volz); Mark Stapp (mjs) Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Bernie, >so the question is: can a DUID-based relay identifier be administered? > if so,=20 > >then we can return that suggestion to the draft. if not, we'll stick > with=20 > >'opaque'. in either case, we'll add text to make it clear that the > identifier=20 > >needs to be administratively-unique. >=20 > Regarding the DUID, that is a complex issue and question. For a device > with storage, if you moved the storage to another device, it would > retain the DUID. So, the DUID is not really something that is hardwired > in this case. Of course, this really only applies to DUID-LLT as that is > the only type that needs to be stored. (The other types are generated > from 'hardwired' data and thus need no storage.) >=20 >=20 > I really don't see why you don't do both? Actually we end up removing DUID from the draft because we could not find a use-case for DUID as relay-id. The two use-cases in this draft needs an administratively configured relay-id. Can you think of any scenario where a DUID relay-id could be useful? > The default identifier that can be used by any device 'out of the box' > is the DUID type. Nothing has to be configured for the device to use > this. >=20 > If the administrator optionally configures an alternative 'opaque' > identifier, then the device uses that instead - with the understanding > that it is up to the administrator to assure that this identifier is > unique. >=20 > Hence, leave the type byte and have the two forms. You get both > capabilities - an identifier that can be used without any configuration > and an identifier that can be used in a case where a stable identifier > across multiple potential "replacement" devices works. The 'type' field came from previous revisions. I think we had unfortunately assumed that DHCP server may parse/interpret the relay-id and so this type field was kept here to indicate what kind of relay-id this sub-option is carrying. After looking at the use cases again, we think we can remove it as DHCP server would never need to parse/interpret it and relay-agent will always know what it has used in relay-id sub-option. Let me know what you think? >=20 > It is an interesting question as to whether we might want to think about > a DUID-OI (Opaque Identifier) at some point to accommodate "locally > administered" identifiers. These would NOT be allowed except when > administratively configured with the understanding that the > administrator must assure it is unique. This would then preclude the > need for a type byte in this suboption and also be useable by DHCPv6 > relay agents. One could even envision that part of the identifier might > include a randomly generated value along the idea of the IPv6 Unique > Local Addresses (ULA) [probably just use the ULA?] as that could avoid > some issues when two administrative domains are collapsed into one. > Perhaps a draft I should think about writing? (If this has merit, > perhaps then your draft is simplified as all it needs to state is using > the DUID.) Yes. I agree. This might be useful. Some time back I think Mark and I were discussing whether we need an administratively configured DUID which can be reused. Thanks, Bharat > The DUID-OI data format could be 6+ octets: > - 6 octets of the 48-bit ULA value (see RFC 4193 - this includes 7-bit > prefix (FC00::/7), L bit, and 40 bit Global ID.) > - octets that follow which are the unique identifier. >=20 > - Bernie >=20 __ -----Original Message----- From: Mark Stapp (mjs) Sent: Monday, June 13, 2011 9:39 AM To: Bernie Volz (volz) Cc: Bharat Joshi; dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt Hi Bernie, yes, I'd also prefer to use a single suboption for this purpose. on the issue of the use of DUID, there's a disagreement. I understood Ted to say that he objected very strongly to any text that proposed 'moving' a DUID from one device to another, or administratively managing DUIDs. I'll let Ted speak for himself, of course, but that's a fundamental issue for this draft. the brief history is: - initial draft just describes opaque identifier, offers two suggestions for assigning id: ascii string and DUID-generating algorithm - someone in WG discussion (David Hankins, maybe?) asked that there be a type-byte. type byte was added. - Ted realized that the draft was proposing to assign DUID generated as relay-id by one device to another device, and objected - Bharat re-issued draft sort of back at initial state, with just opaque id, and no implication that DUID was appropriate so the question is: can a DUID-based relay identifier be administered? if so, then we can return that suggestion to the draft. if not, we'll stick with 'opaque'. in either case, we'll add text to make it clear that the identifier needs to be administratively-unique. Thanks, Mark On 6/13/11 8:59 AM, Bernie Volz (volz) wrote: > First, let me say that I'd MUCH prefer a type field over multiple > suboptions if we feel there is likely to be a need for multiple > identifiers. The reason is that with multiple suboptions, a relay would > potentially need to send more than one (in case a server didn't support > one of the newer suboptions) and it would be much more difficult to > determine which to use / which was used (from the server's / relay's > perspective). > > Second, a DUID is tied to a device (at least the default DUID) but there > is nothing that says you can't configure a replacement device to use the > same DUID as the previous device - though obviously you have to be > careful to assure that the previous device no longer uses that DUID > (either because it is discarded or because it is re-initialized and > generates a new DUID, if DUID-LLT). > > Third, I think if you stick with an opaque identifier, you would need to > be clear to add text that says something like a relay MUST NOT generate > this identifier nor use it until it is ADMINISTRATIVELY configured and > it is up to the administrator then to assure it is unique across the > administrative domain. There is nothing in the draft that states this. > > Fourth, I think having a DUID based identifier is the best option for > most cases. If you want the industrial Ethernet environment where you > need something that is stable across devices, then add a type that > allows this administratively configured identifier. But as a general > relay identifier I would use the DUID. > > So, you might define: > Type =3D 1 - DUID (default type) > Type =3D 2 - Opaque identifier (must only be used if > administratively configured on the device and requires administrator to > assure it is unique). > > - Bernie > > -----Original Message----- > From: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Monday, June 13, 2011 2:45 AM > To: Bernie Volz (volz) > Cc: Mark Stapp (mjs); dhcwg@ietf.org > Subject: RE: [dhcwg] I-D Action: > draft-ietf-dhc-relay-id-suboption-08.txt > > Hi Bernie, > > Thanks a lot for the quick review. Please see my response in line. > > Regards, > Bharat > >> Hi ... I've decided to add the DHC WG as this is a document being > worked >> on there. > Yes. No issues. > >> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger >> argument for this). > That make sense. I can surely do this in next revision. > >> And, I doubt the IESG will be happy with this document and leaving the >> actual identifier as completely opaque! How would this identifying > data >> be assured to be unique if it is just defined as a 'series of octets'? > The draft suggest that this opaque identifier be administratively > configured and there should be a mean to display this to the > administrator. So we expect administrator to be able to take care of > keeping it unique in their own administrative domain. > >> I also fail to see why the DUID isn't being recommended as the > standard >> format for this relay identifier? See RFC 5460 section 5.4, >> OPTION_RELAY_ID. > The previous version of this draft had suggested the use of DUID. But we > had to remove it because our use cases required that same relay-id be > used even if the device is replaced. > >> And, thus do we really need a type field in the option? Isn't just a >> DUID sufficient? > That 'type' field was kept from the previous revision, for the future > extensibility. At present, we feel that an opaque relay-id fulfils works > for our use-cases but in future that may be other use-cases which might > want to use a different type of relay-id. > > In fact, Ted and Pavan had a similar comments. If most of the people > feel that we can define a new sub-option when such a requirements comes, > we can remove this 'type' field. > >> I'd also say that for "compatibility" with DHCPv6, using the DUID as > the >> relay identifier too would be really convenient and appropriate. This >> also means section 6 can probably be significantly scaled back - the >> only issue is the unicast RENEW. > I am not sure if using DUID for the use-cases mentioned in this draft > will be appropriate. > > We had to come out with this new revision because it was pointed out > that DUID cannot be used where same id is required even when the devices > are replaced. > > Once we decide upon whether we can use DUID or not, we can discuss other > points which you have raised here. > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, > you are not > to copy, disclose, or distribute this e-mail or its contents to any > other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys > has taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should > carry out your > own virus checks before opening the e-mail or attachment. Infosys > reserves the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on > the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > From ghalwasi@cisco.com Wed Jun 15 21:15:49 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EEA11E808F for ; Wed, 15 Jun 2011 21:15:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMXnkYwEVe0k for ; Wed, 15 Jun 2011 21:15:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 36B3811E80A3 for ; Wed, 15 Jun 2011 21:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=8206; q=dns/txt; s=iport; t=1308197747; x=1309407347; h=mime-version:subject:date:message-id:from:to:cc; bh=r8bVcPX4kHRofI0XgYui0C0nHTwm6AeK5U+53QtYObc=; b=mBUGowwXnxvxHl/Ni61PRmAVSpEGVtthBwG+WweFoi8MPSmV5h5ZoEsT duS0H3pa9+FZBPQ/zHZ9UuvXIAbY0wWjkA1Wn1tQ/HsDWgx4ZXzmyvM4J vcJjbWHtZoI9XoRKdjMRcdJn/mA5AAjr2SMF/itlpLTEXXawsMBbKkRd3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACSD+U1Io8UR/2dsb2JhbABEDoJRpA53qyieMIMZgw0EhxiPHIsX X-IronPort-AV: E=Sophos;i="4.65,373,1304294400"; d="scan'208,217";a="94195145" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2011 04:15:43 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5G4Fhlj028062 for ; Thu, 16 Jun 2011 04:15:43 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 09:45:43 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2BDC.0EE363E5" Date: Thu, 16 Jun 2011 09:45:41 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B810377576F@XMB-BGL-41E.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification regarding RFC 2131 Thread-Index: Acwr3A3dTCfM2TEsS5Ksx45y9+uvZw== From: "Gaurav Halwasia (ghalwasi)" To: , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 16 Jun 2011 04:15:43.0129 (UTC) FILETIME=[0EFEF090:01CC2BDC] Cc: "GIRI KUTHETHOOR \(gkutheth\)" Subject: [dhcwg] Clarification regarding RFC 2131 X-BeenThere: dhcwg@ietf.org 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, 16 Jun 2011 04:15:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2BDC.0EE363E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 I am presently working on a issue wherein client is sending DHCP packets with zero hardware address. I remember that I initiated a discussion few months back concluding that DHCP packets can indeed have (in few cases though) zero hardware address. =20 Further, RFC says 2 things:- 1. Client-identified option must not be present in downstream packets (DHCPACK/DHCPOFFER). 2. Client identifies the DHCP reply by matching the hardware address/client identifier. =20 In case client has zero mac address, we will end up having in a situation wherein we don't have client identifier and hardware address both in the reply packet and DHCP client won't be able to identify that whether the reply it is receiving is for itself or not. =20 Any thoughts..? =20 Thanks, Gaurav ------_=_NextPart_001_01CC2BDC.0EE363E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Folks,

 

I am presently working on a issue wherein client is = sending DHCP packets with zero hardware address.  I remember that I = initiated a discussion few months back concluding that DHCP packets can = indeed have (in few cases though) zero hardware = address.

 

Further, RFC says 2 things:-

1.       = Client-identified option must not = be present in downstream packets (DHCPACK/DHCPOFFER).

2.       = Client identifies the DHCP reply by matching the = hardware address/client identifier.

 

In case = client has zero mac address, we will end up having  in a situation = wherein we don’t have client identifier and hardware address both = in the reply packet and DHCP client won’t be able to identify that = whether the reply it is receiving is for itself or not.

 

Any = thoughts..?

 

Thanks,

Gaurav

------_=_NextPart_001_01CC2BDC.0EE363E5-- From internet-drafts@ietf.org Thu Jun 16 02:55:57 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CFD11E8102; Thu, 16 Jun 2011 02:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foTo4mKtdaSp; Thu, 16 Jun 2011 02:55:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6D11E8094; Thu, 16 Jun 2011 02:55:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616095557.4822.21952.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 02:55:57 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:55:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Secure DHCPv6 Using CGAs Author(s) : Sheng Jiang Sean Shen Filename : draft-ietf-dhc-secure-dhcpv6-03.txt Pages : 16 Date : 2011-06-16 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-03.txt From akostur@incognito.com Thu Jun 16 04:06:28 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CAD11E822C for ; Thu, 16 Jun 2011 04:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVmE0T60sQJk for ; Thu, 16 Jun 2011 04:06:28 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id A30B011E8213 for ; Thu, 16 Jun 2011 04:06:27 -0700 (PDT) Received: from mail-vw0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKTfnjsnuuUdF4bjT5q0Mybyk8/UQLUXB/@postini.com; Thu, 16 Jun 2011 04:06:27 PDT Received: by vws18 with SMTP id 18so1353473vws.41 for ; Thu, 16 Jun 2011 04:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.74 with SMTP id ew10mr1038786vdb.283.1308222385559; Thu, 16 Jun 2011 04:06:25 -0700 (PDT) Received: by 10.52.188.72 with HTTP; Thu, 16 Jun 2011 04:06:25 -0700 (PDT) In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B810377576F@XMB-BGL-41E.cisco.com> References: <3CF88B99A9ED504197498BC6F6F04B810377576F@XMB-BGL-41E.cisco.com> Date: Thu, 16 Jun 2011 04:06:25 -0700 Message-ID: From: Andre Kostur To: "Gaurav Halwasia (ghalwasi)" Content-Type: multipart/alternative; boundary=20cf3071c6949416d904a5d24277 Cc: dhcwg@ietf.org, "GIRI KUTHETHOOR \(gkutheth\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] Clarification regarding RFC 2131 X-BeenThere: dhcwg@ietf.org 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, 16 Jun 2011 11:06:28 -0000 --20cf3071c6949416d904a5d24277 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There was a draft (draft-ietf-dhc-client-id-00.txt) back in 2004 to try to cover this case, but it doesn't appear to have made it out to RFC status. On Wed, Jun 15, 2011 at 21:15, Gaurav Halwasia (ghalwasi) < ghalwasi@cisco.com> wrote: > Hi Folks, > > > > I am presently working on a issue wherein client is sending DHCP packets > with zero hardware address. I remember that I initiated a discussion few > months back concluding that DHCP packets can indeed have (in few cases > though) zero hardware address. > > > > Further, RFC says 2 things:- > > 1. Client-identified option *must not* be present in downstream > packets (DHCPACK/DHCPOFFER). > > 2. Client identifies the DHCP reply by matching the hardware > address/client identifier. > > > > In case client has zero mac address, we will end up having in a situatio= n > wherein we don=92t have client identifier and hardware address both in th= e > reply packet and DHCP client won=92t be able to identify that whether the > reply it is receiving is for itself or not. > > > > Any thoughts..? > > > > Thanks, > > Gaurav > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf3071c6949416d904a5d24277 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
There was a draft (draft-ietf-dhc-client-id-00.txt) back i= n 2004 to try to cover this case, but it doesn't appear to have made it= out to RFC status.

On Wed, Jun 15, 2011 = at 21:15, Gaurav Halwasia (ghalwasi) <ghalwasi@cisco.com> wrote:

Hi Folks,

=A0=

I am presently working on a issue wherein client is sending DHCP packets wi= th zero hardware address.=A0 I remember that I initiated a discussion few m= onths back concluding that DHCP packets can indeed have (in few cases thoug= h) zero hardware address.

=A0

Further, RFC says 2 th= ings:-

1.=A0=A0=A0=A0=A0=A0 Client-iden= tified option must not be present in downstream packets (DHCP= ACK/DHCPOFFER).

2.=A0=A0=A0=A0=A0=A0 Client identifies the= DHCP reply by matching the hardware address/client identifier.

=A0

In case client has zero mac address, we will = end up having =A0in a situation wherein we don=92t have client identifier a= nd hardware address both in the reply packet and DHCP client won=92t be abl= e to identify that whether the reply it is receiving is for itself or not.<= /p>

=A0

Any thoughts..?

=A0

Thanks,

Gaurav


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




--
Andre Kostur
Se= nior Software Design Engineer
P: 604-678-2864 =A0SIP: 864@incognito.com


--20cf3071c6949416d904a5d24277-- From ghalwasi@cisco.com Thu Jun 16 07:25:44 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69DE11E80F0 for ; Thu, 16 Jun 2011 07:25:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGRUfeJnjkIF for ; Thu, 16 Jun 2011 07:25:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 524B211E8084 for ; Thu, 16 Jun 2011 07:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=12071; q=dns/txt; s=iport; t=1308234342; x=1309443942; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=aJ2KoRa8A5JQkOcdKNeM/bPEOjST9KrsYqhQ8Fkkr3M=; b=JHPNUiCl77BEzQmrVFWt1iJmd45MQT18COTQDzhRxrLqO2s3RDShDBzc GgzFz18qb5/CbiXXdjmq4qo9MWcHWdplO9FEc3TIAv4oqkP3Uxqml6FU7 0W1Qz80U3v9KJtRV3dupWg8d/3PnN9XNuyPsu8NpymYX4Rro279OKb0Iq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAABYS+k1Io8UT/2dsb2JhbABECAaCUZUHhnWIE3erPJ4jgxoagnMEhxuPI4sZ X-IronPort-AV: E=Sophos;i="4.65,375,1304294400"; d="scan'208,217";a="94311546" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2011 14:25:35 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5GEPYBc009783; Thu, 16 Jun 2011 14:25:34 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 19:55:34 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2C31.411A55F7" Date: Thu, 16 Jun 2011 19:51:06 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B8103775934@XMB-BGL-41E.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Clarification regarding RFC 2131 Thread-Index: AcwsFXx/agbzrGNPQcS40y3nRYdFPQAGr18Q References: <3CF88B99A9ED504197498BC6F6F04B810377576F@XMB-BGL-41E.cisco.com> From: "Gaurav Halwasia (ghalwasi)" To: "Andre Kostur" X-OriginalArrivalTime: 16 Jun 2011 14:25:34.0776 (UTC) FILETIME=[41512B80:01CC2C31] Cc: dhcwg@ietf.org, "GIRI KUTHETHOOR \(gkutheth\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] Clarification regarding RFC 2131 X-BeenThere: dhcwg@ietf.org 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, 16 Jun 2011 14:25:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2C31.411A55F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Andre for pointing this out. It seems we need to again persue this in working group. =20 -Gaurav =20 From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Thursday, June 16, 2011 4:36 PM To: Gaurav Halwasia (ghalwasi) Cc: dhcwg@ietf.org; Ralph Droms (rdroms); GIRI KUTHETHOOR (gkutheth) Subject: Re: [dhcwg] Clarification regarding RFC 2131 =20 There was a draft (draft-ietf-dhc-client-id-00.txt) back in 2004 to try to cover this case, but it doesn't appear to have made it out to RFC status. On Wed, Jun 15, 2011 at 21:15, Gaurav Halwasia (ghalwasi) wrote: Hi Folks, =20 I am presently working on a issue wherein client is sending DHCP packets with zero hardware address. I remember that I initiated a discussion few months back concluding that DHCP packets can indeed have (in few cases though) zero hardware address. =20 Further, RFC says 2 things:- 1. Client-identified option must not be present in downstream packets (DHCPACK/DHCPOFFER). 2. Client identifies the DHCP reply by matching the hardware address/client identifier. =20 In case client has zero mac address, we will end up having in a situation wherein we don't have client identifier and hardware address both in the reply packet and DHCP client won't be able to identify that whether the reply it is receiving is for itself or not. =20 Any thoughts..? =20 Thanks, Gaurav _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com =20 =20 ------_=_NextPart_001_01CC2C31.411A55F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Andre for pointing this out. It seems we need to again persue = this in working group.

 

-Gaurav

 

From:= = Andre Kostur [mailto:akostur@incognito.com]
Sent: Thursday, = June 16, 2011 4:36 PM
To: Gaurav Halwasia = (ghalwasi)
Cc: dhcwg@ietf.org; Ralph Droms (rdroms); GIRI = KUTHETHOOR (gkutheth)
Subject: Re: [dhcwg] Clarification = regarding RFC 2131

 

There was a draft = (draft-ietf-dhc-client-id-00.txt) back in 2004 to try to cover this = case, but it doesn't appear to have made it out to RFC = status.

On Wed, Jun 15, 2011 at = 21:15, Gaurav Halwasia (ghalwasi) <ghalwasi@cisco.com> = wrote:

Hi = Folks,

 <= /o:p>

I am = presently working on a issue wherein client is sending DHCP packets with = zero hardware address.  I remember that I initiated a discussion = few months back concluding that DHCP packets can indeed have (in few = cases though) zero hardware address.

 <= /o:p>

Further, = RFC says 2 things:-

1.       = Client-identified option must not be present in = downstream packets (DHCPACK/DHCPOFFER).

2.       = Client identifies the DHCP reply by matching the hardware = address/client identifier.

 <= /o:p>

In case = client has zero mac address, we will end up having  in a situation = wherein we don’t have client identifier and hardware address both = in the reply packet and DHCP client won’t be able to identify that = whether the reply it is receiving is for itself or not.

 <= /o:p>

Any = thoughts..?

 <= /o:p>

Thanks,=

Gaurav<= /o:p>


______________________________________= _________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg




--
Andre = Kostur

Senior Software Design = Engineer

P: 604-678-2864 =  SIP: 864@incognito.com

 

------_=_NextPart_001_01CC2C31.411A55F7-- From akostur@incognito.com Thu Jun 16 09:26:58 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0C61F0C48 for ; Thu, 16 Jun 2011 09:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6YRze+lc5Dg for ; Thu, 16 Jun 2011 09:26:57 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 83C591F0C4D for ; Thu, 16 Jun 2011 09:26:56 -0700 (PDT) Received: from mail-vw0-f50.google.com ([209.85.212.50]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTfouz9xir+EnwkWmWTGZVBzopQQDByjK@postini.com; Thu, 16 Jun 2011 09:26:56 PDT Received: by mail-vw0-f50.google.com with SMTP id 14so1710575vws.23 for ; Thu, 16 Jun 2011 09:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.106.196 with SMTP id gw4mr73821vdb.83.1308241614842; Thu, 16 Jun 2011 09:26:54 -0700 (PDT) Received: by 10.52.188.72 with HTTP; Thu, 16 Jun 2011 09:26:54 -0700 (PDT) In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B8103775934@XMB-BGL-41E.cisco.com> References: <3CF88B99A9ED504197498BC6F6F04B810377576F@XMB-BGL-41E.cisco.com> <3CF88B99A9ED504197498BC6F6F04B8103775934@XMB-BGL-41E.cisco.com> Date: Thu, 16 Jun 2011 09:26:54 -0700 Message-ID: From: Andre Kostur To: "Gaurav Halwasia (ghalwasi)" Content-Type: multipart/alternative; boundary=bcaec5486102bbaafc04a5d6bc97 Cc: dhcwg@ietf.org, "GIRI KUTHETHOOR \(gkutheth\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] Clarification regarding RFC 2131 X-BeenThere: dhcwg@ietf.org 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, 16 Jun 2011 16:26:58 -0000 --bcaec5486102bbaafc04a5d6bc97 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I went digging through the archives the last time this draft was brought up= . There were some changes to be made to the table in the draft (MAY vs MUST)= , and another person expressed a concern that if this was the beginning of options that are being reflected back to the client, perhaps a more generic way of listing which options to which this applied should be created. Although RFC 3011 (2000, vs client-id which was published in 2004) predate= s this draft, and already applies that behaviour to option 118. So I'm not sure that this concern applies. On Thu, Jun 16, 2011 at 07:21, Gaurav Halwasia (ghalwasi) < ghalwasi@cisco.com> wrote: > Thanks Andre for pointing this out. It seems we need to again persue this > in working group. > > > > -Gaurav > > > > *From:* Andre Kostur [mailto:akostur@incognito.com] > *Sent:* Thursday, June 16, 2011 4:36 PM > *To:* Gaurav Halwasia (ghalwasi) > *Cc:* dhcwg@ietf.org; Ralph Droms (rdroms); GIRI KUTHETHOOR (gkutheth) > *Subject:* Re: [dhcwg] Clarification regarding RFC 2131 > > > > There was a draft (draft-ietf-dhc-client-id-00.txt) back in 2004 to try t= o > cover this case, but it doesn't appear to have made it out to RFC status. > > On Wed, Jun 15, 2011 at 21:15, Gaurav Halwasia (ghalwasi) < > ghalwasi@cisco.com> wrote: > > Hi Folks, > > > > I am presently working on a issue wherein client is sending DHCP packets > with zero hardware address. I remember that I initiated a discussion few > months back concluding that DHCP packets can indeed have (in few cases > though) zero hardware address. > > > > Further, RFC says 2 things:- > > 1. Client-identified option *must not* be present in downstream > packets (DHCPACK/DHCPOFFER). > > 2. Client identifies the DHCP reply by matching the hardware > address/client identifier. > > > > In case client has zero mac address, we will end up having in a situatio= n > wherein we don=92t have client identifier and hardware address both in th= e > reply packet and DHCP client won=92t be able to identify that whether the > reply it is receiving is for itself or not. > > > > Any thoughts..? > > > > Thanks, > > Gaurav > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > -- > Andre Kostur > > Senior Software Design Engineer > > P: 604-678-2864 SIP: 864@incognito.com > > > > > --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --bcaec5486102bbaafc04a5d6bc97 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I went digging through the archives the last time this dra= ft was brought up. =A0There were some changes to be made to the table in th= e draft (MAY vs MUST), and another person expressed a concern that if this = was the beginning of options that are being reflected back to the client, p= erhaps a more generic way of listing which options to which this applied sh= ould be created. =A0Although RFC 3011 (2000, vs client-id which was publish= ed in 2004) predates this draft, and already applies that behaviour to opti= on 118. =A0So I'm not sure that this concern applies.


On Thu, Jun 16, 2011 at 07:21= , Gaurav Halwasia (ghalwasi) <ghalwasi@cisco.com> wrote:

Thanks Andre for pointin= g this out. It seems we need to again persue this in working group.<= /p>

=A0

-Gaurav

<= p class=3D"MsoNormal">=A0

From:= Andre Kostur [mailto:akostur@incognito.com]
Se= nt: Thursday, June 16, 2011 4:36 PM
To: Gaurav Halwasia (ghalwasi)
Cc: dhcwg@ietf.org; Ralph Droms (rdroms); GIRI= KUTHETHOOR (gkutheth)
Subject: Re: [dhcwg] Clarification regardi= ng RFC 2131

=A0

=

There was a draft (dr= aft-ietf-dhc-client-id-00.txt) back in 2004 to try to cover this case, but = it doesn't appear to have made it out to RFC status.

On Wed, Jun 15, 2011 at 21:15, Gaurav Halwasia = (ghalwasi) <ghal= wasi@cisco.com> wrote:

Hi Folks,=

=A0

I am presently working= on a issue wherein client is sending DHCP packets with zero hardware addre= ss.=A0 I remember that I initiated a discussion few months back concluding = that DHCP packets can indeed have (in few cases though) zero hardware addre= ss.

=A0

Further, RFC says 2 th= ings:-

1.=A0=A0=A0=A0=A0=A0 Client-identified option must not= be present in downstream packets (DHCPACK/DHCPOFFER).

2.=A0=A0= =A0=A0=A0=A0 Client identifies the DHCP reply by matching the hardwa= re address/client identifier.

=A0

In case client has zero mac address, we will end up having =A0in= a situation wherein we don=92t have client identifier and hardware address= both in the reply packet and DHCP client won=92t be able to identify that = whether the reply it is receiving is for itself or not.

=A0

Any thoughts..?

=A0

Thanks,

Gaurav


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http= s://www.ietf.org/mailman/listinfo/dhcwg




--
Andre Kostur<= /p>

Senior Software Design Engineer

P: 604-678-2864 =A0SIP: 864@incognito.com

=A0




--
Andre Kostur
Senior Software Des= ign Engineer

--bcaec5486102bbaafc04a5d6bc97-- From internet-drafts@ietf.org Mon Jun 20 05:17:13 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CFB11E8163; Mon, 20 Jun 2011 05:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mP9EEH84Q-V; Mon, 20 Jun 2011 05:17:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F21211E815E; Mon, 20 Jun 2011 05:17:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620121712.19315.90827.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 05:17:12 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-pd-exclude-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:17:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation Author(s) : Jouni Korhonen Teemu Savolainen Suresh Krishnan Ole Troan Filename : draft-ietf-dhc-pd-exclude-02.txt Pages : 10 Date : 2011-06-20 This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. The new mechanism updates RFC 3633. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-02.txt From tomasz.mrugalski@gmail.com Mon Jun 20 13:47:48 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B947711E8100 for ; Mon, 20 Jun 2011 13:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4V8UeTQVzmt for ; Mon, 20 Jun 2011 13:47:48 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8100B11E80AF for ; Mon, 20 Jun 2011 13:47:47 -0700 (PDT) Received: by eye13 with SMTP id 13so1517355eye.31 for ; Mon, 20 Jun 2011 13:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oZdeCm3zp4NlgWJNVACwVhMjyg/cS8RFdU3gTGsHVXo=; b=B6R6FmK3R5uaB9U7ZrchVcot74dcyZHnXBRQfRDxDyrCeeGgN+C6NEpeIlOcfzz8Cz 7trMRMZnTKhSyZNPLQ4KAYKMGnwsdAEJ9wnI70ubX8VNJjvkfpTxofQAv9HHDjjxyT9I cXRijVVgwFgx0TEJ2SQVe/hz0ucMKpJbo+Etk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=jDqxu4GiY71cEhuN3Vvr35Ic1GHNwHvEwpWgzzKuMPN6CF7b21Afg4XjpoCbLWNas5 U7IJE74g8RYQklleem2Ea1v5lbLFSiuoUAlUC80RXjT7OL/Nu3BCVARDddHkZHspZQUR NI9a7/d1UF/8D3a5QerolWzlAXj3NOlv8t7NI= Received: by 10.14.126.3 with SMTP id a3mr2016240eei.203.1308602866552; Mon, 20 Jun 2011 13:47:46 -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 s5sm820361ees.24.2011.06.20.13.47.43 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 13:47:43 -0700 (PDT) Message-ID: <4DFFB1EF.4000405@gmail.com> Date: Mon, 20 Jun 2011 22:47:43 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Failover 2011-06-20 meeting notes, 2011-06-27 meeting invitation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:47:48 -0000 Here are the meeting notes from 2011-06-20 DHCPv6 Failover meeting. The next failover meeting is planned for 2011-06-27 10:00 PDT (19:00 CEST) Due to privacy concerns, the audio bridge number for the next meeting is not going to be announced on mailing list. I will send bridge numbers and/or current draft version to anyone who asks, though. Bridge details and draft was sent to 18 interested folks before today's meeting. We are planning to submit -00 of the DHCPv6 failover requirements draft later this week. We will continue to have weekly failover meetings, but they will shift focus to the next step - design document. If you would like to comment on requirements document before it reaches IETF, you should send your comments *now*. Tomek ------------------------------ DHCPv6 Failover discussions minutes June 20 2011, 10:00 PDT, (19:00 CEST) Participants - Alain Maes - Benie Volz - Jack Chen - Kim Kinnear - Shawn Routhier - Tomasz Mrugalski 0.0 Agenda bashing Kim - would like to add a discussion about the arrangement of the current documnet. 1.0 Requirements document 1.1 Recent changes - Kim became co-author - draft is now informational (was standards track) - Network partition recovery is now a MUST - Many editorial changes (thanks to Kim and Bernie) Discussion of document organization Kim suggests putting the requirements list (section 4) towards the end of the document. There wasn't discussion or dissent really so Kim will move the section as part of his integration works. Should we include descriptions of the other possible ways of providing redundancy? Some people think that it's worth having at least a short description of the alternatives for completeness while others feel that this is a failover draft and doesn't really need this and that shrinking the size of the document will make it easier to get reviewed and passed. There wasn't a conclusion and the decision is left to the authors. 1.2 m-to-1 - include in core or define as extension? The experience of several people is that trying to support m to 1 is not worth the extra effort - that the complications outweigh the benefits. We have some other folks that feel that multiple relationships is either necessary or useful. The current position is that any given lease (or pool if you prefer) will be served by a single failover pair. Any given failover server is allowed to participate in multiple relationships if it desires, but for each pool or prefix only a single relationship is allowed. This latter option is more of an implementation detail than a protocol question. There is some question as to the appropriate level - pool, prefix etc - the basic idea is to find an appropirate grouping that can be limited to a single failover pair. 1.3. Next steps - Kim will provide v4-failover-12 digest (1 or 2 pages) - initial -00 submission (this week?) Should we push a draft to the mailing list soon? It may not be quite fully done yet but Bernie points out that it would be useful to hold the discussions in a more public venue so that there is an archive to allow either new participants or ourselves to review the archive for the history of the work. We seem to have concluded to publish as early as possible. Kim has requested comments on the review of DHCPv4 that he has written up and circulated. Tomek suggested adding information about the state machine. This leads to a discussion about how much and which pieces of the DHCPv4 failover document should be included in this document. Some of the items, such as the state machine might be better off in the design document while others might simply be included by adding a reference to the old draft. There is a little concern about if the requirements document could be elevated to RFC status if it has references to the old draft. The requirements draft is being done as an informational draft there is a question about how the design and protocol documents would be handled. Doing them as informational might lower the bar in order to get them passed as an RFC. We are still unclear about the need for inter-vendor interoperability - mostly the conventional wisdom is that this isn't required but we have at least one report that it there is a need for this. Deciding on the appropriate level is something we can do when we start writing the next documents. Suggestion to try and collect any areas of the DHCPv4 failover work that might need to be updated. One question for this is if such information would affect the requirements document or would affect the design document. One area mentioned is the possibility of taking advantage of the larger IPv6 space in order to simplify the design. One concern is that we might be constraining ourselves to the way v4 did things. While there is a general belief that we should use what we can and what makes sense from the DHCPv4 failover there seems to be a belief that we should not be constrained to re-do v4. General question on how to proceed should we continue this series of meetings to work on the design document. What should we say in the security section? Feeling is to go with whatever the standard boiler plate is for requirements documents. We have agreement that we should include a requirement that the failover design must allow for securing the communication between the two peers, though it is not a requirement that they actually do use that capability. It is also desirable that the facility is upgradeable in some fashion. The rest of the agenda was deferred until next meeting. 2. Design document 2.1 Initial discussion on design document: - Goals (design vs protocol) - Timelines (probably not for Quebec, we may meet during IETF, though) 2.2 design topics suggested so far - lazy update - mclt - general state machine - TCP or UDP - Prefix delegation: fixed or variable lengths? - Conflict resolution mechanism: how to decide which data is "best"? Time? Sequence numbers? - transmission of information - design or protocol? Reuse bulk leasequery? - extension support mechanism 2.3 Next steps From Internet-Drafts@ietf.org Mon Jun 20 14:30:02 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600F911E8216; Mon, 20 Jun 2011 14:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Q3mrWlfEAg; Mon, 20 Jun 2011 14:30:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D865411E8218; Mon, 20 Jun 2011 14:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620213001.2886.66926.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 14:30:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-id-suboption-09.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, 20 Jun 2011 21:30:02 -0000 --NextPart 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 : The DHCPv4 Relay Agent Identifier Suboption Author(s) : B. Joshi, et al Filename : draft-ietf-dhc-relay-id-suboption-09.txt Pages : 7 Date : 2011-06-20 This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-relay-id-suboption-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-20141732.I-D@ietf.org> --NextPart-- From bharat_joshi@infosys.com Mon Jun 20 18:27:30 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDFC21F8506 for ; Mon, 20 Jun 2011 18:27:30 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00VLj09JkihF for ; Mon, 20 Jun 2011 18:27:29 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF9621F8505 for ; Mon, 20 Jun 2011 18:27:28 -0700 (PDT) X-TM-IMSS-Message-ID: <94192e2b000f665c@infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 94192e2b000f665c ; Tue, 21 Jun 2011 06:58:49 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Tue, 21 Jun 2011 06:57:24 +0530 From: Bharat Joshi To: "dhcwg@ietf.org" Date: Tue, 21 Jun 2011 06:54:51 +0530 Thread-Topic: New Version Notification - draft-ietf-dhc-relay-id-suboption-09.txt Thread-Index: AcwvkVMDQUVgosmZSummsmRF956OPwAILHKJ Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9F44@BLRKECMBX02.ad.infosys.com> References: <20110620213001.2886.33694.idtracker@ietfa.amsl.com> In-Reply-To: <20110620213001.2886.33694.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] FW: New Version Notification - draft-ietf-dhc-relay-id-suboption-09.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, 21 Jun 2011 01:27:30 -0000 Hi, =20=20=20=20=20=20We=20have=20posted=20an=20updated=20revision=20of=20thi= s=20draft.=20It=20takes=20care=20of=20the=20comments=20received=20on=20th= e=20previous=20version. =20=20=20=20=20=20Major=20changes=20includes: 1.=20Removal=20of=20the=20'type'=20field=20from=20the=20relay-id=20sub-op= tion. 2.=20Adding=20text=20to=20say=20that=20Administrators=20must=20configure= =20the=20opaque=20identifier=20and=20should=20make=20sure=20that=20it=20i= s=20unique=20with=20in=20the=20administrative=20domain. =20=20=20=20=20=20Please=20review=20the=20same=20and=20let=20us=20know=20= your=20comments. Regards, Bharat ________________________________________ From:=20ID=20Tracker=20[internet-drafts-reply@ietf.org] Sent:=20Tuesday,=20June=2021,=202011=203:00=20AM To:=20dhc-chairs@tools.ietf.org;=20draft-ietf-dhc-relay-id-suboption@tool= s.ietf.org;=20rdroms.ietf@gmail.com;=20housley@vigilsec.com;=20adrian@old= dog.co.uk;=20turners@ieca.com Subject:=20New=20Version=20Notification=20-=20draft-ietf-dhc-relay-id-sub= option-09.txt New=20version=20(-09)=20has=20been=20submitted=20for=20draft-ietf-dhc-rel= ay-id-suboption-09.txt. http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-09.= txt Diff=20from=20previous=20version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-id-suboption-09 IETF=20Secretariat. ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From jouni.nospam@gmail.com Tue Jun 21 07:07:32 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4D11E8175 for ; Tue, 21 Jun 2011 07:07: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEOZKQUxt+uG for ; Tue, 21 Jun 2011 07:07:32 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E32D911E814F for ; Tue, 21 Jun 2011 07:07:31 -0700 (PDT) Received: by bwz13 with SMTP id 13so5283565bwz.31 for ; Tue, 21 Jun 2011 07:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QzU7LLpB0ZYbRgGdfu/DfI2PfTmRNc2A8NUOQCW0PwA=; b=wTsNuWtyCKt70xq8NMB6t//u8jLlLr7ayvS0yFpBNO3YHXGi/F3Me8eEE6s011t+dA pYJfcMDkzgNeU61k2o3O/oON3QdMjwYMJPN/KZ7UdCApYC/qSQ6zRYKp+N4dSMYEZmFq 7a+R2nUwSz1LoXXcVg2qqXHysujQwOUeM3D4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=m7NlUISND+4ZkJRtRhB+f70N8Cb7GDuQNidWX8soM62xq+sleVvh9gTRk3y5E0tIpD U37QmKuocrXgsdUvGMmoIE+jr01LN9Stndws3qTyZT118uuRczV4Clvn6bRHD6EEilRl PF7GzwMRpcI2NvCUWLlr3GCxHb5DrlPhw3ldM= Received: by 10.204.232.4 with SMTP id js4mr779695bkb.47.1308665250855; Tue, 21 Jun 2011 07:07:30 -0700 (PDT) Received: from a88-114-168-36.elisa-laajakaista.fi (a88-114-168-36.elisa-laajakaista.fi [88.114.168.36]) by mx.google.com with ESMTPS id af13sm5394760bkc.7.2011.06.21.07.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 07:07:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen Date: Tue, 21 Jun 2011 17:07:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110620121712.19315.90827.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-pd-exclude-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:07:32 -0000 FYI, this version should address the comments received during the WGLC, = except that we did not go for an ORO placed in IA_PD. Additionally we = clarified the subnet ID encoding with a simple pseudo code snippet. - Jouni Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 20, 2011 3:17:12 PM GMT+03:00 > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: I-D Action: draft-ietf-dhc-pd-exclude-02.txt > Reply-To: internet-drafts@ietf.org >=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 : Prefix Exclude Option for DHCPv6-based Prefix = Delegation > Author(s) : Jouni Korhonen > Teemu Savolainen > Suresh Krishnan > Ole Troan > Filename : draft-ietf-dhc-pd-exclude-02.txt > Pages : 10 > Date : 2011-06-20 >=20 > This specification defines an optional mechanism to allow exclusion > of one specific prefix from a delegated prefix set when using = DHCPv6- > based prefix delegation. The new mechanism updates RFC 3633. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-02.txt From rdroms.ietf@gmail.com Tue Jun 21 17:52:14 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44F821F844E; Tue, 21 Jun 2011 17:52:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK9l-NfgHG4Y; Tue, 21 Jun 2011 17:52:14 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C054721F8444; Tue, 21 Jun 2011 17:52:13 -0700 (PDT) Received: by qwc23 with SMTP id 23so214205qwc.31 for ; Tue, 21 Jun 2011 17:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JQj3PzOl2MXDuww05jfske7QlHDGqe7Hwjk7cbDbd48=; b=EcrMSDXIyfnsZr+bYXZmDoj1hi1FVwIoLvaBbiZD/N8qBBwFqNp554ZrWkZcx6WZnT JStMIuDyB1PeaDAx8BP6chbpdBxFcxK/djKvSZe7owcjQquvnwLQIvH61N9XzQPgkCR/ kJO1r6Frz3s+OoQvaXnjBpnECUu8pS9ofryuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=SxAP/jf6kq390BpPoZP8wzv5x5Ync7UomLOqLiZnPYxC2+7QyJVM4UmocGcrnsGW5X +nw7DjB0JpqrmI8jiwR1HU8LO5l2pWOyQcUsKqmByeutD7shD7AIEIzHq2lrzdyK/JqK m35QWafQRrmmmTuV7iSqRGefn79JYFmDVULck= Received: by 10.229.100.20 with SMTP id w20mr36660qcn.129.1308703933054; Tue, 21 Jun 2011 17:52:13 -0700 (PDT) Received: from bxb-rdroms-8716.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id g11sm32111qcm.39.2011.06.21.17.52.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 17:52:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <20110621133345.30498.22812.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 20:52:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <75C2AABE-D308-446D-97E2-819C1767D14D@gmail.com> References: <20110621133345.30498.22812.idtracker@ietfa.amsl.com> To: Adrian Farrel X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , Chairs Dhc , draft-ietf-dhc-subnet-alloc@tools.ietf.org, Ralph Droms , The IESG Subject: Re: [dhcwg] Adrian Farrel's Discuss on draft-ietf-dhc-subnet-alloc-12: (with DISCUSS) X-BeenThere: dhcwg@ietf.org 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, 22 Jun 2011 00:52:14 -0000 Addressing Adrian's DISCUSS, which relates closely to Pete's DISCUSS and = Peter's COMMENT, I suggest that the document be retitled along the lines = of Adrian's suggestion, "Description of Cisco Systems' Subnet Allocation = Option for DHCP" to clarify the content of the document. - Ralph On Jun 21, 2011, at 9:33 AM 6/21/11, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-dhc-subnet-alloc-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm afraid I agree with Pete's Discuss so strongly that I will raise = it as my own Discuss. >=20 > Either this document should be recast as "Description of Cisco = Systems' Subnet Allocation Option for DHCP" (in which case Informational = is acceptable) such that it is obvious what and why people might be = implementing. Or it should be put on to the Standards Track. >=20 > For the avoidance of doubt, I do not object to documents describing = what is in the field and allowing people to decide to interoperate with = that. In particular, in the 3942 context, this is good and proper. But I = do not like the way this document sits on the fence between defining "a = new DHCP option" and being Informaitonal. >=20 >=20 >=20 >=20 From john_brzozowski@cable.comcast.com Thu Jun 23 17:28:28 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BE711E8124 for ; Thu, 23 Jun 2011 17:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE3L6dIiKuHf for ; Thu, 23 Jun 2011 17:28:27 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 833D411E8081 for ; Thu, 23 Jun 2011 17:28:27 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.132162644; Thu, 23 Jun 2011 20:28:23 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Thu, 23 Jun 2011 20:28:23 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: [dhcwg] Agenda items for IETF 81 meeting... Thread-Index: AQHMMgWgsZj8nZdUwEapnAt5ZcZU2A== Date: Fri, 24 Jun 2011 00:28:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc Chairs , Ted Lemon Subject: Re: [dhcwg] Agenda items for IETF 81 meeting... X-BeenThere: dhcwg@ietf.org 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, 24 Jun 2011 00:28:28 -0000 Second call for agenda items, please reply to Ted and myself with requests. Thanks, John On 6/6/11 1:28 PM, "Ted Lemon" wrote: >I'm pretty sure we are going to need to have a meeting, but what with the >overcrowding of the IETF agenda at recent meetings, they'd like us to do >a slightly better job of figuring out exactly how much time we need, and >what we'll be talking about. So if you plan to have a discussion at the >IETF 81 dhcwg meeting, please send in your request for time now. > >Thanks! > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From john_brzozowski@cable.comcast.com Fri Jun 24 13:54:50 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E0911E8238 for ; Fri, 24 Jun 2011 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkVSIbukHHWm for ; Fri, 24 Jun 2011 13:54:49 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2542B11E8224 for ; Fri, 24 Jun 2011 13:54:49 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.132257430; Fri, 24 Jun 2011 16:54:45 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Fri, 24 Jun 2011 16:54:21 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: Please help the Nomcom Thread-Index: AQHMMrCGVGFkktV0p0+V3DxENVsrXJTM/GKA Date: Fri, 24 Jun 2011 20:54:20 +0000 Message-ID: In-Reply-To: <20110624183513.7035311E81A8@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <41DDC25E55CDA24BB1CD6875065CBE37@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] FW: Please help the Nomcom X-BeenThere: dhcwg@ietf.org 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, 24 Jun 2011 20:54:50 -0000 FYI On 6/24/11 2:35 PM, "NomCom Chair" wrote: >Hi WG chairs, > We have had a good response to the first call for volunteers but the >rate at which new volunteers are coming in is slowing down. The Nomcom >process is best served by a large pool of volunteers drawn from a wide >spectrum of IETF attendees. Where else would we find this wide spectrum >if not in the WG mailing lists. > >I would really appreciate it if you can forward the message onto your >working group mailing lists. > >The latest volunteer status and the second call for volunteers can be >found at >https://datatracker.ietf.org/ann/nomcom/2964/ > >Thanks in advance for your help. > >Suresh Krishnan >Nomcom Chair 2011-2012 >Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From tomasz.mrugalski@gmail.com Sun Jun 26 11:47:25 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9801F0C52 for ; Sun, 26 Jun 2011 11:47:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIMY2LZfIwIc for ; Sun, 26 Jun 2011 11:47:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D11F0C53 for ; Sun, 26 Jun 2011 11:47:21 -0700 (PDT) Received: by eye13 with SMTP id 13so1615272eye.31 for ; Sun, 26 Jun 2011 11:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:x-tagtoolbar-keys:content-type:content-transfer-encoding; bh=dyjp+pgVbnoOJhqMfgucgr21Al4r8l+/Wkl5T7/QJII=; b=u0OSRrg+Lguxxc6Pc6QqpDKS2imTrFlDul/HU7+yD0iF9ObAZAX58HhiEcAwPPHZ+l EkQcJMG9x7/RdnLxsmrbb5DWTaUeX3svhtlHfCDLfF1sC4EgmnbDLPSeYVZyXTwhsSJK eEC/p5ACQ59mS2BJAqXl801PMHPDAovW/OUs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-tagtoolbar-keys:content-type:content-transfer-encoding; b=Xocu2foZ+77nu8nxvkOYs4OWINOUZ4OnlZCJ4Cd1uiaNDl71cgyPOCxxcZW9VjhMol NGiL3O0KZSoDunXduftidYPKyczMBwV21dZX9ZPW1qt0DNiBCY2Gz7hyBWv0I16ghPrT FjGujFvtbg1+qxGt3FtKwkt9IiLJE8JXyFaI0= Received: by 10.14.39.206 with SMTP id d54mr3543696eeb.129.1309114040273; Sun, 26 Jun 2011 11:47:20 -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 y6sm3593590eem.4.2011.06.26.11.47.18 (version=SSLv3 cipher=OTHER); Sun, 26 Jun 2011 11:47:18 -0700 (PDT) Message-ID: <4E077EB6.7030702@gmail.com> Date: Sun, 26 Jun 2011 20:47:18 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org X-TagToolbar-Keys: D20110626204718438 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Initial DHCPv6 Failover Requirements draft published X-BeenThere: dhcwg@ietf.org 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, 26 Jun 2011 18:47:25 -0000 Dear group, Thanks to contributions and comments of 10 people and participation of many more, we were able to write this draft is relatively short time. Initial version is available here: http://datatracker.ietf.org/doc/draft-mrugalski-dhc-dhcpv6-failover-requirements/ Comments and suggestions are more than welcome. Now that the draft is published we will try to keep all discussions on list, not just meeting minutes. A reminder: There are weekly audio meetings taking place every Monday, dedicated to v6 failover. The next DHCPv6 failover meeting will take place tomorrow: 2011-06-27 10:00am PDT (19:00 CEST) Due to privacy concerns, the audio bridge number is not going to be announced on mailing list. I will send bridge numbers to anyone who asks, though. Bridge details and draft was sent to 18 interested folks so far. This is the first failover-related draft - a requirements document. It will be followed by design document (work on this draft is expected to begin tomorrow). There is no clear consensus if interoperability between different vendors is really feasible, but if there is enough interest, a third document will also be specified - a protocol spec document. We are trying to keep things simple. It is much easier to succeed with 3 smaller drafts, that one large. Also, we are trying to push as many non-essential features into extensions, so there may be additional extension documents that will cover failover-related areas (e.g. load balancing). We would like to present this draft during Quebec meeting. It probably also makes sense to have v6 failover meeting in Quebec, preferably before DHC meeting. Tomek -------- Original Message -------- Subject: New Version Notification for draft-mrugalski-dhc-dhcpv6-failover-requirements-00.txt Date: Sun, 26 Jun 2011 10:52:58 -0700 From: internet-drafts@ietf.org To: tomasz.mrugalski@gmail.com CC: tomasz.mrugalski@gmail.com, kkinear@cisco.com A new version of I-D, draft-mrugalski-dhc-dhcpv6-failover-requirements-00.txt has been successfully submitted by Tomasz Mrugalski and posted to the IETF repository. Filename: draft-mrugalski-dhc-dhcpv6-failover-requirements Revision: 00 Title: DHCPv6 Failover Requirements Creation date: 2011-06-26 WG ID: Individual Submission Number of pages: 19 Abstract: The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way to decide which server responds to which client queries. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. The IETF Secretariat From ietf-ipr@ietf.org Tue Jun 28 07:34:09 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B41E11E8112; Tue, 28 Jun 2011 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLAukTuN2KYH; Tue, 28 Jun 2011 07:34:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0858511E8108; Tue, 28 Jun 2011 07:34:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: jiangsheng@huawei.com, xiazhongqi@huawei.com X-Test-IDTracker: no Message-ID: <20110628143409.21413.5441.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 07:34:09 -0700 Cc: housley@vigilsec.com, rdroms.ietf@gmail.com, dhcwg@ietf.org, ipr-announce@ietf.org, ted.lemon@nominum.com Subject: [dhcwg] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-dhc-cga-config-dhcpv6-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: Tue, 28 Jun 2011 14:34:09 -0000 Dear Sheng Jiang, Zhongqi Xia: An IPR disclosure that pertains to your Internet-Draft entitled "Configuri= ng Cryptographically Generated Addresses (CGA) using DHCPv6" (draft-ietf-dhc-c= ga- config-dhcpv6) was submitted to the IETF Secretariat on 2011-06-28 and has = been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1582/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-dh= c- cga-config-dhcpv6-00.""); The IETF Secretariat From adrian@olddog.co.uk Wed Jun 22 00:39:04 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97FE21F84E2; Wed, 22 Jun 2011 00:39: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+x-52UmHYIg; Wed, 22 Jun 2011 00:39:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1B43821F84DE; Wed, 22 Jun 2011 00:39:03 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5M7brQB028552; Wed, 22 Jun 2011 08:37:53 +0100 Received: from 950129200 (customer30492.107.wv.cust.t-mobile.co.uk [178.107.119.27] (may be forged)) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5M7blXZ028523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2011 08:37:52 +0100 From: "Adrian Farrel" To: "'Ralph Droms'" References: <20110621133345.30498.22812.idtracker@ietfa.amsl.com> <75C2AABE-D308-446D-97E2-819C1767D14D@gmail.com> In-Reply-To: <75C2AABE-D308-446D-97E2-819C1767D14D@gmail.com> Date: Wed, 22 Jun 2011 08:38:53 +0100 Message-ID: <05ec01cc30af$72f17aa0$58d46fe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQKBXjLEvk7ZdOMduow8pzyX985FcQDl48gTk1dx/iA= X-Mailman-Approved-At: Thu, 30 Jun 2011 08:24:34 -0700 Cc: dhcwg@ietf.org, 'Chairs Dhc' , 'The IESG' , draft-ietf-dhc-subnet-alloc@tools.ietf.org Subject: Re: [dhcwg] Adrian Farrel's Discuss on draft-ietf-dhc-subnet-alloc-12: (with DISCUSS) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 07:39:05 -0000 Hi, This would work for me, but please take the time to look at the Abstract and Introduction as well. They may need an extra line of text to make them as clear as the revised document title. Thanks, Adrian > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: 22 June 2011 01:52 > To: Adrian Farrel > Cc: Ralph Droms; The IESG; Chairs Dhc; draft-ietf-dhc-subnet-alloc@tools.ietf.org; > dhcwg@ietf.org WG > Subject: Re: Adrian Farrel's Discuss on draft-ietf-dhc-subnet-alloc-12: (with > DISCUSS) > > Addressing Adrian's DISCUSS, which relates closely to Pete's DISCUSS and Peter's > COMMENT, I suggest that the document be retitled along the lines of Adrian's > suggestion, "Description of Cisco Systems' Subnet Allocation Option for DHCP" to > clarify the content of the document. > > - Ralph > > On Jun 21, 2011, at 9:33 AM 6/21/11, Adrian Farrel wrote: > > > Adrian Farrel has entered the following ballot position for > > draft-ietf-dhc-subnet-alloc-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I'm afraid I agree with Pete's Discuss so strongly that I will raise it as my own > Discuss. > > > > Either this document should be recast as "Description of Cisco Systems' Subnet > Allocation Option for DHCP" (in which case Informational is acceptable) such that > it is obvious what and why people might be implementing. Or it should be put on > to the Standards Track. > > > > For the avoidance of doubt, I do not object to documents describing what is in > the field and allowing people to decide to interoperate with that. In particular, in > the 3942 context, this is good and proper. But I do not like the way this document > sits on the fence between defining "a new DHCP option" and being > Informaitonal. > > > > > > > > From presnick@qualcomm.com Wed Jun 22 08:16:51 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0DA11E80C4; Wed, 22 Jun 2011 08:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygiqYL+3++qC; Wed, 22 Jun 2011 08:16:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D198C11E80BA; Wed, 22 Jun 2011 08:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1308755810; x=1340291810; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E020710.1070206@qualcomm.com>|Date:=20We d,=2022=20Jun=202011=2010:15:28=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Ralph=20Droms=20|CC:=20Adrian=20Farrel=20, =20"dhcwg@ietf.org=20WG"=20,=0D=0A=09Chai rs=20Dhc=20,=0D=0A=09,=20The=20IESG=20|Subject:=20Re:=20Adrian=20Farrel's=20Discuss =20on=20draft-ietf-dhc-subnet-alloc-12:=20(with=0D=0A=20D ISCUSS)|References:=20<20110621133345.30498.22812.idtrack er@ietfa.amsl.com>=20<75C2AABE-D308-446D-97E2-819C1767D14 D@gmail.com>|In-Reply-To:=20<75C2AABE-D308-446D-97E2-819C 1767D14D@gmail.com>|Content-Type:=20text/plain=3B=20chars et=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=cAfkag9CIpOuG/F7B1EPgA9tdsTvhCe7JavBqmdVkjo=; b=Ow+5PGpkQ8TYlIT0rLzmKNMLoHDNG0KUrci8709bdyNmv5v8hBpzRpvp Az/u9w2wYd/L0Eu/b/sTp0uW8Y6QT+SkoyAS5l0lJxPF8YZ/NdswNspW7 9SalTxlrBBAxLDq68jyM6T7DDRdkszwml2SgukCjxMYQZ0wgdwi7dBMqJ I=; X-IronPort-AV: E=McAfee;i="5400,1158,6384"; a="99363659" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 22 Jun 2011 08:15:31 -0700 X-IronPort-AV: E=Sophos;i="4.65,406,1304319600"; d="scan'208";a="81095176" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Jun 2011 08:15:31 -0700 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 22 Jun 2011 08:15:31 -0700 Message-ID: <4E020710.1070206@qualcomm.com> Date: Wed, 22 Jun 2011 10:15:28 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ralph Droms References: <20110621133345.30498.22812.idtracker@ietfa.amsl.com> <75C2AABE-D308-446D-97E2-819C1767D14D@gmail.com> In-Reply-To: <75C2AABE-D308-446D-97E2-819C1767D14D@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Thu, 30 Jun 2011 08:24:34 -0700 Cc: Adrian Farrel , Chairs Dhc , draft-ietf-dhc-subnet-alloc@tools.ietf.org, The IESG , "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Adrian Farrel's Discuss on draft-ietf-dhc-subnet-alloc-12: (with DISCUSS) X-BeenThere: dhcwg@ietf.org 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, 22 Jun 2011 15:16:51 -0000 Certainly not my preferred approach. I still don't quite understand why this isn't simply going for Proposed Standard. pr On 6/21/11 7:52 PM, Ralph Droms wrote: > Addressing Adrian's DISCUSS, which relates closely to Pete's DISCUSS and Peter's COMMENT, I suggest that the document be retitled along the lines of Adrian's suggestion, "Description of Cisco Systems' Subnet Allocation Option for DHCP" to clarify the content of the document. > > - Ralph > > On Jun 21, 2011, at 9:33 AM 6/21/11, Adrian Farrel wrote: > > >> Adrian Farrel has entered the following ballot position for >> draft-ietf-dhc-subnet-alloc-12: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I'm afraid I agree with Pete's Discuss so strongly that I will raise it as my own Discuss. >> >> Either this document should be recast as "Description of Cisco Systems' Subnet Allocation Option for DHCP" (in which case Informational is acceptable) such that it is obvious what and why people might be implementing. Or it should be put on to the Standards Track. >> >> For the avoidance of doubt, I do not object to documents describing what is in the field and allowing people to decide to interoperate with that. In particular, in the 3942 context, this is good and proper. But I do not like the way this document sits on the fence between defining "a new DHCP option" and being Informaitonal. >> >> >> >> >> > -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From sudurais@gmail.com Mon Jun 27 16:29:52 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE8021F84EC for ; Mon, 27 Jun 2011 16:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfpmRWczT--9 for ; Mon, 27 Jun 2011 16:29:51 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9534121F84DB for ; Mon, 27 Jun 2011 16:29:51 -0700 (PDT) Received: by vws12 with SMTP id 12so5194123vws.31 for ; Mon, 27 Jun 2011 16:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ebDABvtTdtqUSziPSV0cxr/M1/qnvQBxbMTj5cjSVQM=; b=Wrr4Ha/azqZcY9QQrOOJEPe0u8djhAcvkjwaPNrLcHNrPqRtxHiXKP6RcKwt6lYJD8 m2heteEXO2uH89m+6XKh27hPKdRd1bjtOnEqXKHojF6ohy5WUlhr5RlD8y8xuqMtaktC hdMd08r2OxtZtk3khtCbz+p7cAqJ+ICA4qIb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JU45e8DWuxYtdY76lrgdcH3YHGiMmnTH2eECBeDSAHO9CeIwuLMhKNdDn+vrJYClsE J6ivf5+yjbYa4K6r+9IdteBSb5xKnR1c6VM5XkFqwR9rYe6ArAGCTXphCIeX4sAmijV9 fnoBnwDJsrulx3zLKsDwDI7dHmYqx6ULt09W4= MIME-Version: 1.0 Received: by 10.220.110.77 with SMTP id m13mr1265271vcp.180.1309217390916; Mon, 27 Jun 2011 16:29:50 -0700 (PDT) Received: by 10.220.81.10 with HTTP; Mon, 27 Jun 2011 16:29:50 -0700 (PDT) Date: Mon, 27 Jun 2011 16:29:50 -0700 Message-ID: From: sudurais a To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=001636499be584f62504a6b9ed48 X-Mailman-Approved-At: Thu, 30 Jun 2011 08:24:34 -0700 Subject: [dhcwg] DHCPv6 client(proxy) sending unicast packets to server in all dhcp packets. X-BeenThere: dhcwg@ietf.org 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, 27 Jun 2011 23:55:51 -0000 --001636499be584f62504a6b9ed48 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I've question regarding DHCPv6 server behavior for Unicasted DHCP packets from DHCPv6 clients(Proxy clients - Neither a Relay or Client. Proxy client has a valid IPv6 address but for its subscribers its acting as Proxy which also includes some of Relay Agent Options to identify binding of address returned by server). In our application, we know server IPv6 addresses forehand and also client(Proxy client) needs to go across routers (routing-domain) to communicate with server. In that case, multicast/broadcast isn't viable solution from DHCPv6 Proxy client. If DHCPv6 client does unicast DISCOVER packet to server and uses unicast for all of its communication with server, will it be a problem in server side ?. Is server mandates client should be sending packets with bcast/mcast address as destination address in DHCP discover or request packets ?. Thanks in advance, Regards, sudurais. --001636499be584f62504a6b9ed48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

I've question regarding DHCPv6 server behavior for Unica= sted DHCP packets from DHCPv6 clients(Proxy clients - Neither a Relay or Cl= ient. Proxy client has a valid IPv6 address but for its subscribers its act= ing as Proxy which also includes some of Relay Agent Options to identify bi= nding of address returned by server). In our application, we know server IP= v6 addresses forehand and also client(Proxy client) needs to go across rout= ers (routing-domain) to communicate with server. In that case, multicast/br= oadcast isn't viable solution from DHCPv6 Proxy client. If DHCPv6 clien= t does unicast DISCOVER packet to server and uses unicast for all of its co= mmunication with server, will it be a problem in server side ?. Is server m= andates client should be sending packets with bcast/mcast address as destin= ation address in DHCP discover or request packets ?.

Thanks in advance,

Regards,
sudurais.

--001636499be584f62504a6b9ed48-- From Ted.Lemon@nominum.com Thu Jun 30 08:50:13 2011 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDCC11E8181 for ; Thu, 30 Jun 2011 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9La2MGgg5ag for ; Thu, 30 Jun 2011 08:50:12 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 57FF611E8177 for ; Thu, 30 Jun 2011 08:50:11 -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 DSNKTgybM7kvG3UhFoVbUGN/lIL/wAtpjT7r@postini.com; Thu, 30 Jun 2011 08:50: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 D7B371B8374 for ; Thu, 30 Jun 2011 08:50: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 C80CD190060; Thu, 30 Jun 2011 08:50:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 30 Jun 2011 08:50:11 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 30 Jun 2011 08:50:10 -0700 MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: multipart/alternative; boundary="Apple-Mail=_79AE5F42-EA3D-4AB3-A190-80A9F70B8E9F" From: Ted Lemon In-Reply-To: Date: Thu, 30 Jun 2011 11:50:06 -0400 Message-ID: <78BE6B04-4B0E-4B4F-9D77-E9F55ACF5C69@nominum.com> References: To: sudurais a X-Mailer: Apple Mail (2.1242) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 client(proxy) sending unicast packets to server in all dhcp packets. X-BeenThere: dhcwg@ietf.org 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, 30 Jun 2011 15:50:13 -0000 --Apple-Mail=_79AE5F42-EA3D-4AB3-A190-80A9F70B8E9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Jun 27, 2011, at 7:29 PM, sudurais a wrote: > If DHCPv6 client does unicast DISCOVER packet to server and uses = unicast for all of its communication with server, will it be a problem = in server side ?. Is server mandates client should be sending packets = with bcast/mcast address as destination address in DHCP discover or = request packets ?. The server is expected to ignore any such packets. I presume that you = mean "Solicit," not "DISCOVER," since there is no "DISCOVER" packet in = DHCPv6. --Apple-Mail=_79AE5F42-EA3D-4AB3-A190-80A9F70B8E9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" If DHCPv6 = client does unicast DISCOVER packet to server and uses unicast for all = of its communication with server, will it be a problem in server side ?. = Is server mandates client should be sending packets with bcast/mcast = address as destination address in DHCP discover or request packets = ?.
The server is expected to ignore = any such packets.   I presume that you mean "Solicit," not = "DISCOVER," since there is no "DISCOVER" packet in = DHCPv6.

= --Apple-Mail=_79AE5F42-EA3D-4AB3-A190-80A9F70B8E9F--