From mcglothine@ambrosi.com Mon Dec 1 09:18:33 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C463A68A9 for ; Mon, 1 Dec 2008 09:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.989 X-Spam-Level: X-Spam-Status: No, score=-15.989 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_SHAWCABLE_2=1.45, HOST_EQ_MODEMCABLE=1.368, HOST_EQ_SHAWCAB=1.8, HOST_EQ_SHAWCABLE=1.222, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC8dtM2FCxbS for ; Mon, 1 Dec 2008 09:18:32 -0800 (PST) Received: from S010600179a210623.vs.shawcable.net (S010600179a210623.vs.shawcable.net [24.86.131.73]) by core3.amsl.com (Postfix) with SMTP id C049D3A6856 for ; Mon, 1 Dec 2008 09:18:31 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201171831.C049D3A6856@core3.amsl.com> Date: Mon, 1 Dec 2008 09:18:31 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Mon Dec 1 13:29:12 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7803A6BB1; Mon, 1 Dec 2008 13:29:12 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31553A67A4 for ; Mon, 1 Dec 2008 13:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE2SIATv7S9e for ; Mon, 1 Dec 2008 13:29:11 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 01C0A28C0D8 for ; Mon, 1 Dec 2008 13:29:11 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A7AF61986F9; Mon, 1 Dec 2008 23:29:06 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 447E9198661; Mon, 1 Dec 2008 23:29:06 +0200 (EET) Message-ID: <4934570E.1010305@piuha.net> Date: Mon, 01 Dec 2008 23:28:46 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Dhcwg X-Virus-Scanned: ClamAV using ClamSMTP Cc: Carlos Pignataro , Russ Housley Subject: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Folks, I recently wrote a draft about the IANA rules regarding ARP, as no such rules were defined before. During last call, it became apparent that there are a few other protocols that use the same numbers. For instance, specialized forms of ARP for certain link layers or DHCPv4/6. Having realized this, we did a more thorough search of the RFC series to attempt to find all such uses. The new version of my draft lists all these uses and updates the RFCs in question. I would like to ask for your review to make sure (a) that the ARP rule change is OK from the perspective of your protocol and (b) we have found all uses of the ARP numbers. Here's what the draft says: "The change is also applicable to extensions of ARP that use the same message format, such as [RFC0903], [RFC1931], and [RFC2390]. The change also affects other protocols that employ values from the ARP name spaces. For instance, the ARP hardware address type (ar$hrd) number space is also used in the "htype" (hardware address type) fields in Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are therefore affected by the update in the IANA rules. Other affected specifications include the specialized address resolution mechanisms in HYPERchannel [RFC1044], DHCP options [RFC2132], [RFC4361], ATM (Asynchronous Transfer Mode) ARP [RFC2225], HARP (High-Performance Parallel Interface ARP) [RFC2834], [RFC2835], Dual MAC FDDI (Fiber Distributed Data Interface) ARP [RFC1329], MAPOS (Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy) ARP [RFC2176], FC (Fibre Channel) ARP [RFC4338], and DNS Resource Records [RFC4701]." (We have only listed a protocol as affected when uses ARP values directly, e.g., in its own protocol message formats. Use of ARP as-is is of course not an issue. I have also not listed the many IP over Foo specifications that talk about how to use ARP in Foo, describing what hardware type values to use, etc.) Here's the URL for the draft: http://tools.ietf.org/html/draft-arkko-arp-iana-rules-04 Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Dec 1 15:03:04 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD7528C0F9; Mon, 1 Dec 2008 15:03:04 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CBD428C127 for ; Mon, 1 Dec 2008 15:03:03 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLHSKbwfN5YN for ; Mon, 1 Dec 2008 15:03:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CEB7328C0EA for ; Mon, 1 Dec 2008 15:03:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,698,1220227200"; d="scan'208";a="29620822" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2008 23:02:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB1N2vnr018766; Mon, 1 Dec 2008 18:02:57 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB1N2tCO004480; Mon, 1 Dec 2008 23:02:57 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 18:02:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 18:02:53 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109C80E14@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <4934570E.1010305@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules Thread-Index: AclT/viCAdMoK9gmTzSVDz9vV316dQACaXqg References: <4934570E.1010305@piuha.net> From: "Bernie Volz (volz)" To: "Jari Arkko" , "Dhcwg" X-OriginalArrivalTime: 01 Dec 2008 23:02:55.0785 (UTC) FILETIME=[F2450190:01C95408] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3037; t=1228172577; x=1229036577; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20DHCP=20impacts=20from=20draft -arkko-arp-iana-rules |Sender:=20 |To:=20=22Jari=20Arkko=22=20,=20=22Dh cwg=22=20; bh=cs5KEXrr2/twSPdvksvxY13oxCgypKGki58Y4kDbrFo=; b=VhbARpDwvLZ3MIkDn1jh1NywXRWJF5CjuIa5hGRm7pDRVsFg79F6COYnW7 Zol1pN/T5cpdwfAGqXUeq97dObiOVU7+94TdlURWkspQpqu82nYIaaCjtE/y BZrRVAQm0I; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "Carlos Pignataro \(cpignata\)" , Russ Housley Subject: Re: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hum ... Didn't realize this was such a problem. There's no issue that I can see with DHCPv4 - you've addressed the 1-octet issue for future assignments because of the limit on the htype field. For DHCPv6, there is no issue as it has a 2-octet field. Thus, draft looks OK to me. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Monday, December 01, 2008 4:29 PM To: Dhcwg Cc: Carlos Pignataro (cpignata); Russ Housley Subject: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules Folks, I recently wrote a draft about the IANA rules regarding ARP, as no such rules were defined before. During last call, it became apparent that there are a few other protocols that use the same numbers. For instance, specialized forms of ARP for certain link layers or DHCPv4/6. Having realized this, we did a more thorough search of the RFC series to attempt to find all such uses. The new version of my draft lists all these uses and updates the RFCs in question. I would like to ask for your review to make sure (a) that the ARP rule change is OK from the perspective of your protocol and (b) we have found all uses of the ARP numbers. Here's what the draft says: "The change is also applicable to extensions of ARP that use the same message format, such as [RFC0903], [RFC1931], and [RFC2390]. The change also affects other protocols that employ values from the ARP name spaces. For instance, the ARP hardware address type (ar$hrd) number space is also used in the "htype" (hardware address type) fields in Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are therefore affected by the update in the IANA rules. Other affected specifications include the specialized address resolution mechanisms in HYPERchannel [RFC1044], DHCP options [RFC2132], [RFC4361], ATM (Asynchronous Transfer Mode) ARP [RFC2225], HARP (High-Performance Parallel Interface ARP) [RFC2834], [RFC2835], Dual MAC FDDI (Fiber Distributed Data Interface) ARP [RFC1329], MAPOS (Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy) ARP [RFC2176], FC (Fibre Channel) ARP [RFC4338], and DNS Resource Records [RFC4701]." (We have only listed a protocol as affected when uses ARP values directly, e.g., in its own protocol message formats. Use of ARP as-is is of course not an issue. I have also not listed the many IP over Foo specifications that talk about how to use ARP in Foo, describing what hardware type values to use, etc.) Here's the URL for the draft: http://tools.ietf.org/html/draft-arkko-arp-iana-rules-04 Jari _______________________________________________ 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 dhcwg-bounces@ietf.org Tue Dec 2 04:04:03 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372463A6992; Tue, 2 Dec 2008 04:04:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07343A67D7 for ; Tue, 2 Dec 2008 04:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.471 X-Spam-Level: X-Spam-Status: No, score=-5.471 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFbga4OTkYlL for ; Tue, 2 Dec 2008 04:04:00 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4F63E3A686C for ; Tue, 2 Dec 2008 04:04:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,701,1220227200"; d="scan'208";a="29702143" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2008 12:03:38 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB2C3cRI000383; Tue, 2 Dec 2008 07:03:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB2C3bQI005704; Tue, 2 Dec 2008 12:03:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 07:03:37 -0500 Received: from bxb-rdroms-8717.cisco.com ([10.98.10.88]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 07:03:36 -0500 Message-Id: From: Ralph Droms To: Jari Arkko In-Reply-To: <8E296595B6471A4689555D5D725EBB2109C80E14@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 07:03:30 -0500 References: <4934570E.1010305@piuha.net> <8E296595B6471A4689555D5D725EBB2109C80E14@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 02 Dec 2008 12:03:36.0755 (UTC) FILETIME=[01A9D030:01C95476] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3860; t=1228219418; x=1229083418; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20DHCP=20impacts=20from=20draft -arkko-arp-iana-rules |Sender:=20 |To:=20Jari=20Arkko=20; bh=mbsjailou0Bao56RcjuPMvESJZoe/g7wSmNa2ORcK2I=; b=IcceLVGc54E1qyUXJZSeEyLgNsrf32lxR7Rqd43K/EmLhhESkbmELVUZmF /j3wZ9PfPCKo5FT/OCM9ZnjJuPKoWijyX9slWqj8I50K35+5UeDdVQag4/Wk AB2qVPjIxf; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , "Carlos Pignataro \(cpignata\)" , Russ Housley , "Bernie Volz \(volz\)" , Droms Ralph Subject: Re: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Jari - I agree with Bernie's analysis about the impact of your draft on DHCPv*. I have a question about the mechanics of the request to IANA: do you want to specify how the request to IANA is documented? For example, RFC 2939 requires that new DHCP options be documented in an RFC before IANA receives a request for the associated option code. Will a simple request to IANA, for example through http://iana.org/cgi-bin/assignments.pl , be sufficient for new ARP codes? - Ralph On Dec 1, 2008, at Dec 1, 2008,6:02 PM, Bernie Volz (volz) wrote: > Hum ... Didn't realize this was such a problem. > > There's no issue that I can see with DHCPv4 - you've addressed the > 1-octet issue for future assignments because of the limit on the htype > field. For DHCPv6, there is no issue as it has a 2-octet field. > > Thus, draft looks OK to me. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Jari Arkko > Sent: Monday, December 01, 2008 4:29 PM > To: Dhcwg > Cc: Carlos Pignataro (cpignata); Russ Housley > Subject: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules > > > Folks, > > I recently wrote a draft about the IANA rules regarding ARP, as no > such > rules were defined before. > > During last call, it became apparent that there are a few other > protocols that use the same numbers. For instance, specialized forms > of > ARP for certain link layers or DHCPv4/6. Having realized this, we > did a > more thorough search of the RFC series to attempt to find all such > uses. > > The new version of my draft lists all these uses and updates the > RFCs in > > question. > > I would like to ask for your review to make sure (a) that the ARP rule > change is OK from the perspective of your protocol and (b) we have > found > > all uses of the ARP numbers. Here's what the draft says: > > "The change is also applicable to extensions of ARP that use the same > message format, such as [RFC0903], [RFC1931], and [RFC2390]. > > The change also affects other protocols that employ values from the > ARP > name spaces. For instance, the ARP hardware address type (ar$hrd) > number space is also used in the "htype" (hardware address type) > fields > in Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration > Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in > the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are > therefore affected by the update in the IANA rules. Other affected > specifications include the specialized address resolution mechanisms > in > HYPERchannel [RFC1044], DHCP options [RFC2132], [RFC4361], ATM > (Asynchronous Transfer Mode) ARP [RFC2225], HARP (High-Performance > Parallel Interface ARP) [RFC2834], [RFC2835], Dual MAC FDDI (Fiber > Distributed Data Interface) ARP [RFC1329], MAPOS (Multiple Access > Protocol over Synchronous Optical Network/Synchronous Digital > Hierarchy) > > ARP [RFC2176], FC (Fibre Channel) ARP [RFC4338], and DNS Resource > Records [RFC4701]." > > (We have only listed a protocol as affected when uses ARP values > directly, e.g., in its own protocol message formats. Use of ARP as- > is is > > of course not an issue. I have also not listed the many IP over Foo > specifications that talk about how to use ARP in Foo, describing what > hardware type values to use, etc.) > > Here's the URL for the draft: > http://tools.ietf.org/html/draft-arkko-arp-iana-rules-04 > > Jari > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From oyec@afo.net Tue Dec 2 07:03:01 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85833A67D7 for ; Tue, 2 Dec 2008 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.192 X-Spam-Level: X-Spam-Status: No, score=-11.192 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6L+27fKnLoQ for ; Tue, 2 Dec 2008 07:03:01 -0800 (PST) Received: from activeinfotech.com (unknown [95.37.39.83]) by core3.amsl.com (Postfix) with SMTP id F19113A6768 for ; Tue, 2 Dec 2008 07:02:56 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081202150257.F19113A6768@core3.amsl.com> Date: Tue, 2 Dec 2008 07:02:56 -0800 (PST) Click here to view as a webpage. From dhcwg-bounces@ietf.org Tue Dec 2 08:49:39 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07BB28C117; Tue, 2 Dec 2008 08:49:39 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B05428C117 for ; Tue, 2 Dec 2008 08:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS4jkhqQsvMB for ; Tue, 2 Dec 2008 08:49:37 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 71A6F28C10B for ; Tue, 2 Dec 2008 08:49:37 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 101D8198718; Tue, 2 Dec 2008 18:49:33 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id ABDFF198646; Tue, 2 Dec 2008 18:49:32 +0200 (EET) Message-ID: <49356708.7080700@piuha.net> Date: Tue, 02 Dec 2008 18:49:12 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Ralph Droms References: <4934570E.1010305@piuha.net> <8E296595B6471A4689555D5D725EBB2109C80E14@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , "Bernie Volz \(volz\)" , "Carlos Pignataro \(cpignata\)" Subject: Re: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph, Bernie, > Jari - I agree with Bernie's analysis about the impact of your draft > on DHCPv*. Good -- I just wanted to know its not a problem. > I have a question about the mechanics of the request to IANA: do you > want to specify how the request to IANA is documented? For example, > RFC 2939 requires that new DHCP options be documented in an RFC before > IANA receives a request for the associated option code. Will a simple > request to IANA, for example through > http://iana.org/cgi-bin/assignments.pl, be sufficient for new ARP codes? These depend on the particular namespace. For ar$op, we specified IETF Review or IESG Approval. The former involves the publication of an RFC from the IETF. The latter is for exceptional situations and we'd have to consider the circumstances to decide what is going to be required. But I'd say we would probably require an RFC even in this case. For ar$hrd, individual values can be allocated via FCFS. However, one byte values require expert review. No special requirements have been set for the documentation in either case. You could argue that such requirements should be set. But note that my draft is already a tightening of the rules from the current unspecified situation. We don't want to make things too hard, either. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 2 11:50:18 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7443A6B57; Tue, 2 Dec 2008 11:50:18 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079483A6B57 for ; Tue, 2 Dec 2008 11:50:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd58GYK8ILZ4 for ; Tue, 2 Dec 2008 11:50:17 -0800 (PST) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by core3.amsl.com (Postfix) with ESMTP id 240613A6B47 for ; Tue, 2 Dec 2008 11:50:15 -0800 (PST) Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mB2IVg9v010539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 14:49:54 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-172.cs.dartmouth.edu [129.170.212.172] by newblitzen.Dartmouth.EDU (Mac) via SMTP for id <137447613>; 02 Dec 2008 14:49:53 -0500 Message-ID: <4935915E.1060708@Dartmouth.edu> Date: Tue, 02 Dec 2008 14:49:50 -0500 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Ralph Droms , DHC-WG X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-From: massimiliano.pala@dartmouth.edu Subject: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1184315687==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1184315687== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070103090006070902060409" This is a cryptographically signed message in MIME format. --------------ms070103090006070902060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ralph, DHC-WG, as discussed in Minneapolis, I published the new version (01) of the I-D about the PKI Resource Query Protocol (PRQP) as an Experimental draft from the PKIX WG: http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt I would need the expertise from your WG to validate the DHCP part of the I-D. In particular, the section that provides guidelines for the distribution of the PRQP Server(RQA) address is B.1. Please let me know what the next steps should be... -- Best Regards, Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] Massimiliano.Pala@dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov --------------ms070103090006070902060409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjAy MTk0OTUwWjAjBgkqhkiG9w0BCQQxFgQUGkYaTNiuBvIKDtcr0Fqfl6Mx75AwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYB0WHFH81tT5nGEu6o6l2KwC7XIKbsevLImTU4E01v1MnlD00xyzVQSp1gRhr5Qx0oKXbEt zNlRfVXfZGOp7EA9HM47/RPq/Snu3Bfi2wPU0Qjyz6corkmO7p4BKLcBGImvLxIiROL5CvnA OSq8eOq2P05LACEPYSy1bHVjEWfH+wAAAAAAAA== --------------ms070103090006070902060409-- --===============1184315687== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1184315687==-- From dhcwg-bounces@ietf.org Tue Dec 2 12:11:46 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608AF3A68BE; Tue, 2 Dec 2008 12:11:46 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199A83A68BE for ; Tue, 2 Dec 2008 12:11:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL0k2En5+baK for ; Tue, 2 Dec 2008 12:11:44 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 1FD383A67BD for ; Tue, 2 Dec 2008 12:11:44 -0800 (PST) Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSTWWe70rYjd7f51VA1FGm4Cvj3lo9oLm@postini.com; Tue, 02 Dec 2008 12:11:40 PST Received: from [192.168.1.127] (c-76-105-204-34.hsd1.or.comcast.net [76.105.204.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 86CC41A8205; Tue, 2 Dec 2008 12:11:38 -0800 (PST) (envelope-from neild@nominum.com) Message-Id: From: Damien Neil To: Massimiliano Pala In-Reply-To: <4935915E.1060708@Dartmouth.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 12:11:37 -0800 References: <4935915E.1060708@Dartmouth.edu> X-Mailer: Apple Mail (2.929.2) Cc: DHC-WG Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Dec 2, 2008, at 11:49 AM, Massimiliano Pala wrote: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt > > I would need the expertise from your WG to validate the DHCP part of > the I-D. At first glance, two issues jump out at me: Section B.1.1 does not indicate whether the option is for DHCPv4 or DHCPv6. The option code and length fields are 16 bits wide, which implies DHCPv6, but the examples in subsequent sections imply DHCPv4. DHCPv4 options encode the option code and length as a single octet each. (Section B.1.1 also references RFC 3315, implying DHCPv6.) Section B.1.1 specifies that the option contains a list of DNS names, but the ISC DHCP examples in section B.1.2 are for an option containing a list of IPv4 addresses. - Damien _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ministerialness@a54321.com Wed Dec 3 07:21:14 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C37D3A67A8 for ; Wed, 3 Dec 2008 07:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.679 X-Spam-Level: X-Spam-Status: No, score=-22.679 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_CUST=0.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PunUSDOqeZPV for ; Wed, 3 Dec 2008 07:21:13 -0800 (PST) Received: from 194-23-106-237.customer.telia.com (194-23-106-237.customer.telia.com [194.23.106.237]) by core3.amsl.com (Postfix) with SMTP id B88A63A67E6 for ; Wed, 3 Dec 2008 07:21:12 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203152112.B88A63A67E6@core3.amsl.com> Date: Wed, 3 Dec 2008 07:21:12 -0800 (PST) Click here to view as a webpage. From dhcwg-bounces@ietf.org Fri Dec 5 03:50:59 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5433A6C67; Fri, 5 Dec 2008 03:50:59 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC823A6C66 for ; Fri, 5 Dec 2008 03:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+Fr6Cb39KMQ for ; Fri, 5 Dec 2008 03:50:56 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A3DC03A6C62 for ; Fri, 5 Dec 2008 03:50:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,721,1220227200"; d="scan'208";a="30064522" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Dec 2008 11:50:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB5Bop0j015772 for ; Fri, 5 Dec 2008 06:50:51 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB5BopaY002474 for ; Fri, 5 Dec 2008 11:50:51 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 06:50:51 -0500 Received: from bxb-rdroms-8712.cisco.com ([10.98.10.83]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 06:50:51 -0500 Message-Id: <1DBEF0D3-DBDF-4787-87DB-511B133DA949@cisco.com> From: Ralph Droms To: Dhcwg WG Content-Type: multipart/mixed; boundary=Apple-Mail-6318-1062537115 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 06:50:40 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Dec 2008 11:50:51.0477 (UTC) FILETIME=[B8C2E850:01C956CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2356; t=1228477851; x=1229341851; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Review=20of=20draft-ietf-netlmm-pmip6-ipv4-supp ort |Sender:=20 |To:=20Dhcwg=20WG=20; bh=5IA84p6ag/+b48QW4i0Q2HC3LMFPVpxGoF4rsgddCdg=; b=cuk0w2y5Yg0Y0UZkceG2tBOhQGtOhYUUVGLhgRIwkrWtwFMH2SOj8C5W3R pPWzlUZELg6zlSD2oXG/oRjUOc9B9afD4WFOnJU2Mpmt8WAezgOctM1al9RY lBJgKBeQwN; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [dhcwg] Review of draft-ietf-netlmm-pmip6-ipv4-support X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --Apple-Mail-6318-1062537115 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I'd like to get dhc WG review of draft-ietf-netlmm-pmip6-ipv4-support (details below). I'm especially interested in taking a close look at mobile node identification to the DHCP service and the ways in which multiple DHCP servers may have to be coordinated for mobile nodes using IPv4 and DHCP. Please cross-post any responses to netlmm@ietf.org Thanks... - Ralph ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. Title : IPv4 Support for Proxy Mobile IPv6 Author(s) : R. Wakikawa, S. Gundavelli Filename : draft-ietf-netlmm-pmip6-ipv4-support-06.txt Pages : 49 Date : 2008-11-27 This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-06.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. --Apple-Mail-6318-1062537115 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-11-27200120.I-D@ietf.org>

--Apple-Mail-6318-1062537115 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-6318-1062537115 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-6318-1062537115-- From mooneyx@amidoduco.com Fri Dec 5 09:08:26 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C13A28C1A6 for ; Fri, 5 Dec 2008 09:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.716 X-Spam-Level: ** X-Spam-Status: No, score=2.716 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfYaGUwuoucn for ; Fri, 5 Dec 2008 09:08:26 -0800 (PST) Received: from net-93-150-29-250.t2.dsl.vodafone.it (net-93-150-29-250.t2.dsl.vodafone.it [93.150.29.250]) by core3.amsl.com (Postfix) with SMTP id 284BF28C18B for ; Fri, 5 Dec 2008 09:08:21 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205170823.284BF28C18B@core3.amsl.com> Date: Fri, 5 Dec 2008 09:08:21 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Fri Dec 5 12:50:41 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AE93A698F; Fri, 5 Dec 2008 12:50:41 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37183A698F for ; Fri, 5 Dec 2008 12:50:39 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id namz4pOuSDGo for ; Fri, 5 Dec 2008 12:50:39 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 133233A68FD for ; Fri, 5 Dec 2008 12:50:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,722,1220227200"; d="scan'208";a="114286886" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 05 Dec 2008 20:50:34 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB5KoYYC002145 for ; Fri, 5 Dec 2008 12:50:34 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB5KoKq0019284 for ; Fri, 5 Dec 2008 20:50:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 15:50:29 -0500 Received: from dhcp-161-44-112-22.cisco.com ([161.44.112.22]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 15:50:28 -0500 Message-Id: From: Ralph Droms To: Dhcwg WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 15:50:18 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Dec 2008 20:50:29.0165 (UTC) FILETIME=[1B5E05D0:01C9571B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1502; t=1228510234; x=1229374234; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-vp n-option-09.txt |Sender:=20; bh=ehgUVordr9Cq9vyN+0vS3xC6sBoFjnoIwcBe341Hbzw=; b=myQ5OYsCxbhyGFR3ynl4/iwNM01yvidffQO5vz1MDwUquqHqXTzt3ALGxs Po4Cfjh5GwEjqRubpwUXHVhi9Za3zea7ZXf+1rh2sqEy55LspYG//bn5BvU8 ihjso8CDQBXFR3jwmft3M3RneM8ln/WgooHVtExbRXe5HkBa6gtVs=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "Virtual Subnet Selection Options for DHCPv4 and DHCPv6" . The last call will conclude at 1700PDT on December 19, 2008. This document is intended for publication as a Draft Standard. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. Note that there was only one response to the previous WG lst call for this document, which is at http://trac.tools.ietf.org/wg/dhc/trac/ticket/12. That response will be considered as part of this new WG last call. draft-ietf-dhc-vpn-option-09.txt defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-09.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 12:56:36 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF663A6B27; Fri, 5 Dec 2008 12:56:35 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFE83A69F2 for ; Fri, 5 Dec 2008 12:56:34 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKb65wb2a3Qk for ; Fri, 5 Dec 2008 12:56:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2D1933A6B27 for ; Fri, 5 Dec 2008 12:56:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,722,1220227200"; d="scan'208";a="30153957" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Dec 2008 20:56:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB5KuN7B021741 for ; Fri, 5 Dec 2008 15:56:23 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB5KuN5U020648 for ; Fri, 5 Dec 2008 20:56:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 15:56:23 -0500 Received: from dhcp-161-44-112-22.cisco.com ([161.44.112.22]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 15:56:22 -0500 Message-Id: <7199B856-9333-430D-B6D4-E54290C54A6D@cisco.com> From: Ralph Droms To: Dhcwg WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 15:56:10 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Dec 2008 20:56:22.0980 (UTC) FILETIME=[EE41E840:01C9571B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1095; t=1228510586; x=1229374586; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-dh cpv6-reconfigure-rebind-06 |Sender:=20 |To:=20Dhcwg=20WG=20; bh=NFSPu6ww2oifGRbC7sbb2S6Xfv6hlKC12QdK9ZtMF70=; b=K08yNMTpfNurd7Y++Y3YF+TBxBQjJYnaz1zMsj27iv/gAjyck8azXmvYYI kjRlmRDkTvsJOep6o1l1NTta1sNH9K0hDrj9Ii8NPA6N7j3E1t/aqH8nHbx7 teaHlGh1Sh; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "Rebind Capability in DHCPv6 Reconfigure Messages" . The last call will conclude at 1700PDT on 12/19/2008. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. There was insufficient response during the previous WG last call for this document to advance it to the IESG. draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which allows DHCPv6 servers to instruct clients to perform a Rebind operation as well as a Renew operation. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 13:03:12 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047D93A6BA0; Fri, 5 Dec 2008 13:03:12 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690503A6BA8 for ; Fri, 5 Dec 2008 13:03:11 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEf7CP5YfyZp for ; Fri, 5 Dec 2008 13:03:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6656D3A6B8A for ; Fri, 5 Dec 2008 13:03:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,722,1220227200"; d="scan'208";a="30190237" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Dec 2008 21:03:05 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB5L3459025838 for ; Fri, 5 Dec 2008 16:03:04 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB5L34iR004930 for ; Fri, 5 Dec 2008 21:03:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 16:03:04 -0500 Received: from dhcp-161-44-112-22.cisco.com ([161.44.112.22]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 16:03:04 -0500 Message-Id: <3FB6A7DB-3BF8-4610-A7D3-0C3B1EB86975@cisco.com> From: Ralph Droms To: Dhcwg WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 16:02:58 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Dec 2008 21:03:04.0369 (UTC) FILETIME=[DD810210:01C9571C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1286; t=1228510984; x=1229374984; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-re lay-id-suboption-04.txt |Sender:=20 |To:=20Dhcwg=20WG=20; bh=iylGG18Lo9yNZ7FJ4e/6rItkXezptO7pY35yYyIQLo0=; b=XIR5AApfxmThCjF3N9GHjYq6dlDNLq05jw0nKm/HToqMLUiV4epsFKm2nr WjH82Ppj94wU1xUxVsgb7mwogRjm7Aha4dBUlqYixPzFL4qUIbwCQxoofYX6 sJ/fZk35SC; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "The DHCPv4 Relay Agent Identifier Suboption" . The last call will conclude at 1700PDT on December 19, 2008. This document is intended for publication as a Proposed Standard. The -04 revision of the document includes changes based on the comments received during the previous last call. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-relay-id-suboption-04.txt defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a unique identifier configured or generated at the relay agent. The suboption allows a DHCP relay agent to include the unique identifier in the DHCP messages it sends. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 13:43:52 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A1F3A69DE; Fri, 5 Dec 2008 13:43:52 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6A93A6BC2 for ; Fri, 5 Dec 2008 13:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6CT2D5p6zEq for ; Fri, 5 Dec 2008 13:43:50 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 86BCE3A69DE for ; Fri, 5 Dec 2008 13:43:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,722,1220227200"; d="scan'208";a="30194766" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Dec 2008 21:43:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB5LhUMp018723 for ; Fri, 5 Dec 2008 16:43:30 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB5LhUJr016997 for ; Fri, 5 Dec 2008 21:43:30 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 16:43:30 -0500 Received: from 161.44.112.22 ([161.44.112.22]) by xmb-rtp-212.amer.cisco.com ([64.102.31.111]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Dec 2008 21:43:29 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 05 Dec 2008 16:43:27 -0500 From: Ralph Droms To: DHC WG Message-ID: Thread-Topic: dhc WG last call on "Guidelines for Creating New DHCP Options" Thread-Index: AclXIoGBqsfoFVT6QJS8R8uEE6eMuQ== Mime-version: 1.0 X-OriginalArrivalTime: 05 Dec 2008 21:43:30.0320 (UTC) FILETIME=[837BC100:01C95722] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=965; t=1228513410; x=1229377410; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20last=20call=20on=20=22Guidelines=20f or=20Creating=20New=20DHCP=20Options=22 |Sender:=20 |To:=20DHC=20WG=20; bh=31vZcNTMqNb9142IpZQwO2RJxfSeR80KoiZiYlAlZd8=; b=jUFMmewNnFlTt+yRmQs305ElbyQANI7uuIF+MJ868dgMKJlhBJQQzqUJZD 0W09aqKCZW+kXCXUi0kOTIR5IeUIkrZue6I1IRVHEBOE2/es4vqC1cQIL37y 8gPH9mf9hn; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [dhcwg] dhc WG last call on "Guidelines for Creating New DHCP Options" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "Guidelines for Creating New DHCP Options)" . This document is intended for publication as a Proposed Standard. The last call will conclude at 1700 PDT on 12/19/2008. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. "Guidelines for Creating New DHCP Options" seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 13:59:41 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AB128C190; Fri, 5 Dec 2008 13:59:40 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B84728C194 for ; Fri, 5 Dec 2008 13:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJHe+xHtgEPc for ; Fri, 5 Dec 2008 13:59:39 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 36E6628C1B0 for ; Fri, 5 Dec 2008 13:58:43 -0800 (PST) Received: from localhost ([127.0.0.1]:60430 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8ih0-00033I-GQ; Fri, 05 Dec 2008 22:58:34 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 21:58:34 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/15 Message-ID: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: [dhcwg] [dhc] #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: vpn-option | Version: Severity: In WG Last Call | Keywords: ------------------------------+--------------------------------------------- The WG last call for draft-ietf-dhc-vpn-option will terminate at 1700PDT on 10/20/2008. The discussion thread for this WG last call is at http://www.ietf.org /mail-archive/web/dhcwg/current/msg09264.html A comment from the previous WG last call, http://trac.tools.ietf.org/wg/dhc/trac/ticket/12, will be considered as part of this WG last call -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:00:01 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450E628C179; Fri, 5 Dec 2008 14:00:01 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DA23A6BC2 for ; Fri, 5 Dec 2008 14:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suAbXgU47xse for ; Fri, 5 Dec 2008 14:00:00 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 706F028C179 for ; Fri, 5 Dec 2008 13:59:58 -0800 (PST) Received: from localhost ([127.0.0.1]:60458 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8iiE-00034S-Uu; Fri, 05 Dec 2008 22:59:50 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 21:59:50 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/13#comment:2 Message-ID: <066.2a678a015acd7cff586ae7fa28e95d8d@tools.ietf.org> References: <057.1f0bbb1103810e0d75b14f6ff7d488ba@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <057.1f0bbb1103810e0d75b14f6ff7d488ba@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #13: WG last call for draft-ietf-dhc-vpn-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #13: WG last call for draft-ietf-dhc-vpn-option ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: vpn-option | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by rdroms@cisco.com): * status: new => closed * resolution: => fixed -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:04:15 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15FC28C14C; Fri, 5 Dec 2008 14:04:15 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8573A6403 for ; Fri, 5 Dec 2008 14:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJTXyswvZjB8 for ; Fri, 5 Dec 2008 14:04:13 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 2CC6C3A67B5 for ; Fri, 5 Dec 2008 14:04:11 -0800 (PST) Received: from localhost ([127.0.0.1]:47313 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8imG-0003Im-Uv; Fri, 05 Dec 2008 23:04:00 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:04:00 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/16 Message-ID: <057.2620d12a4a98427d4f882fc3819079c9@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: [dhcwg] [dhc] #16: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #16: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind ---------------------------------------+------------------------------------ Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: dhcpv6-reconfigure-rebind | Version: Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ The WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind will end at 1700PDT on 12/19/2008. The discussion thread for this WG last call is at www.ietf.org/mail- archive/web/dhcwg/current/msg09265.html -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:04:54 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1518928C179; Fri, 5 Dec 2008 14:04:54 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EFB28C179 for ; Fri, 5 Dec 2008 14:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfc09Te3BVQW for ; Fri, 5 Dec 2008 14:04:52 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id D945728C1A4 for ; Fri, 5 Dec 2008 14:04:51 -0800 (PST) Received: from localhost ([127.0.0.1]:47323 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8imv-0003Jo-Ru; Fri, 05 Dec 2008 23:04:41 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:04:41 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/7#comment:3 Message-ID: <066.749d7b29d6461dbb57f5b7bbd41ca4af@tools.ietf.org> References: <057.ba0822afd8c0596ce4001d737ca7c662@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <057.ba0822afd8c0596ce4001d737ca7c662@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #7: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #7: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind ---------------------------------------+------------------------------------ Reporter: rdroms@cisco.com | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: dhcpv6-reconfigure-rebind | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by rdroms@cisco.com): * status: new => closed * resolution: => fixed -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:05:43 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E76428C14C; Fri, 5 Dec 2008 14:05:43 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206E73A6A05 for ; Fri, 5 Dec 2008 14:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 288otffQv97z for ; Fri, 5 Dec 2008 14:05:41 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 422013A67B5 for ; Fri, 5 Dec 2008 14:05:41 -0800 (PST) Received: from localhost ([127.0.0.1]:47345 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8inl-0003SP-MJ; Fri, 05 Dec 2008 23:05:33 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:05:33 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/15#comment:1 Message-ID: <066.8f762ed5f3aa902b1f2576abc9dc6b49@tools.ietf.org> References: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: vpn-option | Version: Severity: In WG Last Call | Resolution: Keywords: | ------------------------------+--------------------------------------------- Description changed by rdroms@cisco.com: Old description: > The WG last call for draft-ietf-dhc-vpn-option will terminate at 1700PDT > on 10/20/2008. > > The discussion thread for this WG last call is at http://www.ietf.org > /mail-archive/web/dhcwg/current/msg09264.html > > A comment from the previous WG last call, > http://trac.tools.ietf.org/wg/dhc/trac/ticket/12, will be considered as > part of this WG last call New description: The WG last call for draft-ietf-dhc-vpn-option will terminate at 1700PDT on 12/19/2008. The discussion thread for this WG last call is at http://www.ietf.org /mail-archive/web/dhcwg/current/msg09264.html A comment from the previous WG last call, http://trac.tools.ietf.org/wg/dhc/trac/ticket/12, will be considered as part of this WG last call -- -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:08:11 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59BD3A67B5; Fri, 5 Dec 2008 14:08:11 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562E53A67B5 for ; Fri, 5 Dec 2008 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVVLu46rLpph for ; Fri, 5 Dec 2008 14:08:10 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 7BDA93A6403 for ; Fri, 5 Dec 2008 14:08:10 -0800 (PST) Received: from localhost ([127.0.0.1]:37050 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8iq1-0003wE-NQ; Fri, 05 Dec 2008 23:07:53 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:07:53 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/17 Message-ID: <057.f52fd136593ae14a05d8d1e25a6f62a7@tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: [dhcwg] [dhc] #17: WG last call on draft-ietf-dhc-relay-id-suboption X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #17: WG last call on draft-ietf-dhc-relay-id-suboption --------------------------------+------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: relay-id-suboption | Version: Severity: In WG Last Call | Keywords: --------------------------------+------------------------------------------- The WG last call on draft-ietf-dhc-relay-id-suboption will end at 1700PDT 12/19/08 The discussion thread for this WG last call is at www.ietf.org/mail- archive/web/dhcwg/current/msg09266.html -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:08:35 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221C028C1D8; Fri, 5 Dec 2008 14:08:35 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F2F28C1D8 for ; Fri, 5 Dec 2008 14:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo8RJdfImm2p for ; Fri, 5 Dec 2008 14:08:33 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id C57C228C1CB for ; Fri, 5 Dec 2008 14:08:32 -0800 (PST) Received: from localhost ([127.0.0.1]:37063 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8iqX-0000kg-AU; Fri, 05 Dec 2008 23:08:25 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:08:24 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/5#comment:2 Message-ID: <066.c6ed49371263e9fc25694578a41b184a@tools.ietf.org> References: <057.7e440166c813292233e86e5325d55397@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <057.7e440166c813292233e86e5325d55397@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #5: WG last call on draft-ietf-dhc-relay-id-suboption X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #5: WG last call on draft-ietf-dhc-relay-id-suboption --------------------------------+------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: relay-id-suboption | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by rdroms@cisco.com): * status: new => closed * resolution: => fixed -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:09:26 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7FB3A67B5; Fri, 5 Dec 2008 14:09:26 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0793A6A05 for ; Fri, 5 Dec 2008 14:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU80TsH6bE8L for ; Fri, 5 Dec 2008 14:09:23 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id B7FDF3A67B5 for ; Fri, 5 Dec 2008 14:09:23 -0800 (PST) Received: from localhost ([127.0.0.1]:37087 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8irL-0001eI-Tb; Fri, 05 Dec 2008 23:09:15 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:09:15 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/6#comment:3 Message-ID: <066.25f9acb515949f417c7898356b63cdd7@tools.ietf.org> References: <057.326db2fcddbe00449e6fcdf12792b8af@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <057.326db2fcddbe00449e6fcdf12792b8af@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #6: WG last call for draft-ietf-dhc-container-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #6: WG last call for draft-ietf-dhc-container-opt ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: container-opt | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by rdroms@cisco.com): * status: new => closed * resolution: => fixed -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:10:10 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37C83A67B5; Fri, 5 Dec 2008 14:10:10 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1603A67B5 for ; Fri, 5 Dec 2008 14:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9CeS0HF9w55 for ; Fri, 5 Dec 2008 14:10:05 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id DFA123A6403 for ; Fri, 5 Dec 2008 14:10:04 -0800 (PST) Received: from localhost ([127.0.0.1]:37103 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8is1-0001fb-Qu; Fri, 05 Dec 2008 23:09:57 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:09:57 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/11#comment:2 Message-ID: <066.a82a231eb5f23eb643242709e3e145e8@tools.ietf.org> References: <057.65a439768353739d943b44a9d2287698@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <057.65a439768353739d943b44a9d2287698@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #11: WG last call for draft-ietf-dhc-l2ra X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #11: WG last call for draft-ietf-dhc-l2ra ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: l2ra | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by rdroms@cisco.com): * status: new => closed * resolution: => fixed -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:14:10 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60E028C1A4; Fri, 5 Dec 2008 14:14:10 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD15B3A6928 for ; Fri, 5 Dec 2008 14:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmgfPCT7bKFo for ; Fri, 5 Dec 2008 14:14:09 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id CDF523A67B5 for ; Fri, 5 Dec 2008 14:14:08 -0800 (PST) Received: from localhost ([127.0.0.1]:35327 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8ivx-0001EJ-OU; Fri, 05 Dec 2008 23:14:01 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:14:01 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/18 Message-ID: <057.a390fae3a085806038e71fb2560101fe@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: [dhcwg] [dhc] #18: WG last call on draft-ietf-dhc-option-guidelines-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #18: WG last call on draft-ietf-dhc-option-guidelines-03.txt -------------------------------+-------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: option-guidelines | Version: Severity: In WG Last Call | Keywords: -------------------------------+-------------------------------------------- This message announces a WG last call on "Guidelines for Creating New DHCP Options)" . The last call will conclude at 1700 PDT on 12/19/2008. -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 5 14:14:49 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1503A6928; Fri, 5 Dec 2008 14:14:49 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253E03A6928 for ; Fri, 5 Dec 2008 14:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32gdVtlxLcB6 for ; Fri, 5 Dec 2008 14:14:46 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 40D4E3A67B5 for ; Fri, 5 Dec 2008 14:14:46 -0800 (PST) Received: from localhost ([127.0.0.1]:35334 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L8iwZ-0003HZ-7P; Fri, 05 Dec 2008 23:14:39 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 05 Dec 2008 22:14:39 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/18#comment:1 Message-ID: <066.3275578da75f2d544197d0bb3b53e384@tools.ietf.org> References: <057.a390fae3a085806038e71fb2560101fe@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <057.a390fae3a085806038e71fb2560101fe@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #18: WG last call on draft-ietf-dhc-option-guidelines-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #18: WG last call on draft-ietf-dhc-option-guidelines-03.txt -------------------------------+-------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: option-guidelines | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------+-------------------------------------------- Description changed by rdroms@cisco.com: Old description: > This message announces a WG last call on "Guidelines for Creating New > DHCP Options)" . The last call > will > conclude at 1700 PDT on 12/19/2008. New description: This message announces a WG last call on "Guidelines for Creating New DHCP Options)" . The last call will conclude at 1700 PDT on 12/19/2008. The discussion thread for this WG last call begins at http://www.ietf.org /mail-archive/web/dhcwg/current/msg09267.html -- -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Dec 6 03:35:57 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9DB3A684F; Sat, 6 Dec 2008 03:35:57 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B463A6841 for ; Sat, 6 Dec 2008 03:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siFZ+-9JvxG5 for ; Sat, 6 Dec 2008 03:35:55 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2E3B03A684F for ; Sat, 6 Dec 2008 03:35:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,724,1220227200"; d="scan'208";a="30234319" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2008 11:35:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB6BZn9j001462; Sat, 6 Dec 2008 06:35:49 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB6BZno2029196; Sat, 6 Dec 2008 11:35:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Dec 2008 06:35:49 -0500 Received: from bxb-rdroms-8712.cisco.com ([10.98.10.83]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Dec 2008 06:35:48 -0500 Message-Id: From: Ralph Droms To: Massimiliano Pala In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 6 Dec 2008 06:35:42 -0500 References: <4935915E.1060708@Dartmouth.edu> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Dec 2008 11:35:48.0751 (UTC) FILETIME=[C91B99F0:01C95796] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1214; t=1228563349; x=1229427349; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20PKIX=20WG=20new=20I-D=20draft =3A=20DHCP=20section=20review |Sender:=20 |To:=20Massimiliano=20Pala=20; bh=JlDM6WzSx5NUX2An2rrmKWiVVq1aw0VhyD8QyEe35YI=; b=PxXSt49oblz+/zNaZTiwvnTBMnlokar71/AxGJRSZvNOqIvX/OWfCZH2Yv 3KiD1tcggpi04xxLsY2XawIdAFnUJ9D6LK3LcIKDpD4CeKjMyRKBh/ppFDZS 2NVlOXbi9R; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DHC-WG , Damien Neil Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I agree with Damien's review. Take a look at RFC 4280 for an example of how to write parallel definitions for an option in DHCPv4 and DHCPv6. - Ralph On Dec 2, 2008, at Dec 2, 2008,3:11 PM, Damien Neil wrote: > On Dec 2, 2008, at 11:49 AM, Massimiliano Pala wrote: >> http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt >> >> I would need the expertise from your WG to validate the DHCP part >> of the I-D. > > At first glance, two issues jump out at me: > > Section B.1.1 does not indicate whether the option is for DHCPv4 or > DHCPv6. The option code and length fields are 16 bits wide, which > implies DHCPv6, but the examples in subsequent sections imply > DHCPv4. DHCPv4 options encode the option code and length as a > single octet each. (Section B.1.1 also references RFC 3315, > implying DHCPv6.) > > Section B.1.1 specifies that the option contains a list of DNS > names, but the ISC DHCP examples in section B.1.2 are for an option > containing a list of IPv4 addresses. > > - Damien > _______________________________________________ > 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 dhcwg-bounces@ietf.org Sat Dec 6 14:54:06 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EE63A687E; Sat, 6 Dec 2008 14:54:06 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7373A687E for ; Sat, 6 Dec 2008 14:54:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq6fxkSwRKSS for ; Sat, 6 Dec 2008 14:54:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 720A23A680A for ; Sat, 6 Dec 2008 14:54:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,726,1220227200"; d="scan'208";a="30257487" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2008 22:53:58 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB6MrwlQ019033 for ; Sat, 6 Dec 2008 17:53:58 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB6MrwJV018832 for ; Sat, 6 Dec 2008 22:53:58 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Dec 2008 17:53:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 6 Dec 2008 17:53:57 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109D42514@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <7199B856-9333-430D-B6D4-E54290C54A6D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call ondraft-ietf-dhc-dhcpv6-reconfigure-rebind-06 Thread-Index: AclXG/8AZY2wkmALTf2woKO+nUynJAA2XxUg References: <7199B856-9333-430D-B6D4-E54290C54A6D@cisco.com> From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , "Dhcwg WG" X-OriginalArrivalTime: 06 Dec 2008 22:53:58.0541 (UTC) FILETIME=[861CD3D0:01C957F5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1564; t=1228604038; x=1229468038; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20last=20call=20ondr aft-ietf-dhc-dhcpv6-reconfigure-rebind-06 |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =20=22Dhcwg=20WG=22=20; bh=jgI1DDSsbn+Cwf9D7Ym35T2DS8/uxPMjGLMX3DJHuBA=; b=0V5JTtWcAjxBXIAeBYiX3Mu2+MFW3MIi/e4bPhOWmnDAG3iJhHowxEH7ZT tq9cOeSo8IBjLFCjn4zobx9kBf0lwlcJ6hIwgGcuwDaxCSC14IR2MClwW6mD 14C9u8maNI; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] dhc WG last call ondraft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I support this document advancing "as is". - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Friday, December 05, 2008 3:56 PM To: Dhcwg WG Subject: [dhcwg] dhc WG last call ondraft-ietf-dhc-dhcpv6-reconfigure-rebind-06 This message announces a WG last call on "Rebind Capability in DHCPv6 Reconfigure Messages" . The last call will conclude at 1700PDT on 12/19/2008. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. There was insufficient response during the previous WG last call for this document to advance it to the IESG. draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which allows DHCPv6 servers to instruct clients to perform a Rebind operation as well as a Renew operation. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-re bind-06.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ 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 majordomo@al-amal.net Sat Dec 6 17:36:19 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1442A3A6A1F for ; Sat, 6 Dec 2008 17:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.435 X-Spam-Level: X-Spam-Status: No, score=-13.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZYoKEh7UVk6 for ; Sat, 6 Dec 2008 17:36:19 -0800 (PST) Received: from 125-63.73-24.tampabay.res.rr.com (125-63.73-24.tampabay.res.rr.com [24.73.63.125]) by core3.amsl.com (Postfix) with SMTP id 0A0C63A6A10 for ; Sat, 6 Dec 2008 17:36:17 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207013618.0A0C63A6A10@core3.amsl.com> Date: Sat, 6 Dec 2008 17:36:17 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From kh_chan@afcd.gov.hk Sat Dec 6 22:43:03 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9DF28C0CF for ; Sat, 6 Dec 2008 22:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.627 X-Spam-Level: X-Spam-Status: No, score=-11.627 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGJ2ozmp9Rkd for ; Sat, 6 Dec 2008 22:43:02 -0800 (PST) Received: from ahm.honda.com (173-23-107-148.client.mchsi.com [173.23.107.148]) by core3.amsl.com (Postfix) with SMTP id 84A8728B797 for ; Sat, 6 Dec 2008 22:42:59 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207064301.84A8728B797@core3.amsl.com> Date: Sat, 6 Dec 2008 22:42:59 -0800 (PST) Click to visit Official Web Site! From nelss@acme.com Sun Dec 7 07:51:45 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211033A6992 for ; Sun, 7 Dec 2008 07:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.768 X-Spam-Level: X-Spam-Status: No, score=-23.768 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OdYw2Qo24Bf for ; Sun, 7 Dec 2008 07:51:45 -0800 (PST) Received: from ab-consul.co.jp (unknown [189.70.161.158]) by core3.amsl.com (Postfix) with SMTP id C5F553A6909 for ; Sun, 7 Dec 2008 07:51:43 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207155143.C5F553A6909@core3.amsl.com> Date: Sun, 7 Dec 2008 07:51:43 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Sun Dec 7 08:51:04 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F053A69CA; Sun, 7 Dec 2008 08:51:04 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C1F3A69C9 for ; Sun, 7 Dec 2008 08:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lu2fFCmhaB6 for ; Sun, 7 Dec 2008 08:51:02 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 51AE43A6847 for ; Sun, 7 Dec 2008 08:51:02 -0800 (PST) Received: from localhost ([127.0.0.1]:36651 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L9MqI-0001oZ-Tt; Sun, 07 Dec 2008 17:50:51 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Sun, 07 Dec 2008 16:50:50 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/16#comment:1 Message-ID: <066.cd27dc48c03c0f57597222e08fac4d46@tools.ietf.org> References: <057.2620d12a4a98427d4f882fc3819079c9@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <057.2620d12a4a98427d4f882fc3819079c9@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #16: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #16: WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind ---------------------------------------+------------------------------------ Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: dhcpv6-reconfigure-rebind | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------------ Old description: > The WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind will end at > 1700PDT on 12/19/2008. > > The discussion thread for this WG last call is at www.ietf.org/mail- > archive/web/dhcwg/current/msg09265.html New description: The WG last call for draft-ietf-dhc-dhcpv6-reconfigure-rebind will end at 1700PDT on 12/19/2008. The discussion thread for this WG last call is at www.ietf.org/mail- archive/web/dhcwg/current/msg09265.html -- Comment(by rdroms@cisco.com): From http://www.ietf.org/mail-archive/web/dhcwg/current/msg09283.html Subject: RE: [dhcwg] dhc WG last call ondraft-ietf-dhc-dhcpv6-reconfigure- rebind-06 Date: Sat, 6 Dec 2008 17:53:57 -0500 rom: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , "Dhcwg WG" I support this document advancing "as is". - Bernie ===== -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Dec 8 09:26:48 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229813A6864; Mon, 8 Dec 2008 09:26:48 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D944028C100 for ; Mon, 8 Dec 2008 09:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeXHv+53X0Y for ; Mon, 8 Dec 2008 09:26:44 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8535A3A6825 for ; Mon, 8 Dec 2008 09:26:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,736,1220227200"; d="txt'?scan'208";a="30352227" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2008 17:26:37 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB8HQbfF013125 for ; Mon, 8 Dec 2008 12:26:37 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB8HQb5v010070 for ; Mon, 8 Dec 2008 17:26:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 12:26:37 -0500 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 12:26:37 -0500 Message-Id: From: Ralph Droms To: DHC-WG WG Content-Type: multipart/mixed; boundary=Apple-Mail-1726--805590616 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 12:26:35 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Dec 2008 17:26:37.0427 (UTC) FILETIME=[1FEC2C30:01C9595A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=26527; t=1228757197; x=1229621197; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20*DRAFT*=20WG=20meeting=20minutes=20from=20Minne apolis |Sender:=20 |To:=20DHC-WG=20WG=20; bh=2OfPDHF1c/dIq511UNeDqKmywP+thYXokd8D2oT+Ez0=; b=IHmywpeSAu9un1D5S5dmkTG9Sbg4DRfGFB11PLtkJjyHlTppG4+IzhJWci 5TPJW9WHi/IKqmOzkNiX3OGkDxdkk5rsskM+fwmON0MHHE5xE0UPvQ6esYmD DDt9gj6wpZ; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [dhcwg] *DRAFT* WG meeting minutes from Minneapolis X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --Apple-Mail-1726--805590616 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Attached are draft minutes from the recent WG meeting. Please respons with adds/changes/deletes by Fri, Dec 12. - Ralph -----DHC Working group Thursday, November 20, 2008 Thanks to Ted Lemon for taking notes at the meeting, on which these minutes are based. [Agenda] Alper asked about the DHC Auth analysis. John will give status update. [DHC WG I-D status] draft-ietf-dhc-subnet-alloc --------------------------- Richard Johnson is confused because there were comments on subnet alloc draft which he hasn't addressed yet, he thinks he needs to do a revision before it goes to IESG. They were mostly nitpicks, he says. Ralph: let's take a note of that and deal with that offline. draft-ietf-dhc-vpn-option ------------------------- Kim Kinnear: I revised the draft based on the comments in the previous previous last call, there were only one set of minor comments from Bernie that said we didn't have to do anything about them, I figured I'd fold them in if there were any other comments from last call, they were mostly textual. I think it's ready for review now. Ralph: didn't get enough review last time. Bernie Volz agreed to review the draft. Ted agreed to do it; you'd better hassle him about it later. David Hankins also agreed to review the draft, in absentia. Kim: what we have now is ready for review, there are three textual comments, one minor possible misunderstanding, I'm sure there will be other similar comments, so not planning to review the draft again until this review is complete. draft-ietf-dhc-dhcpv6-reconfigure-rebind ---------------------------------------- Bernie, Richard and Ted Lemon agreed to review during a new WG last call. draft-ietf-dhc-relay-id-suboption --------------------------------- Bernie, Kim and Ted agreed to review during a new WG last call. draft-ietf-dhc-l2ra, draft-miles-dhc-dhcpv6-ldra ------------------------------------------------ These two drafts need to be correlated so that boilerplate describing problem space is the same or similar, even though mechanisms are different. Ralph is asking everyone to read the docs together so that we can discuss on mailing list. Ralph will kick off discussion. DHCP Auth analysis ------------------ John reports that we're slightly behind schedule. The review team has completed its preliminary review/analysis, and is currently planning on giving a draft version of that analysis to Jari Arkko (dhc WG Internet AD) in January. At that point the review team is going to determine the next step based on whether we get a revised version of the draft. We want to make sure the analysis we do is accurate with respect to the new revision. [Reviews of dhc WG I-Ds] DHCPv6 Remote Boot Options --------------------------------------------------------------------------- Vincent Zimmer from Intel. He's working on EFI in the UEFI forum. PXE is evolving within UEFI, and the latest UEFI spec has IPv6. Problem: what will the boot paradigm scenarios look like on IPv6? We can define APIs but on the wire we felt it was best to come to the IETF and work those. Question: Who will manage the "processor architecture type"? Make it an expert-reviewed IANA managed list. DHCPv6 option for network boot --------------------------------------------------------------------- (no presentation) Discussion of previous two drafts: Question for the group: how should the authors of the two drafts work together? Bernie: Is the next-server option was a good idea given that the URI option already contains that info? Ted: Is the PXE stuff was driving idiosyncracies in the protocol. Ralph wants them to try to reconcile the two drafts offline. DHCPv4 Vendor-specific Message , DHCP Vendor-specific Message ------------------------------------------------------------------------ Both drafts were dsicussed together. Kim: Leasequery had a message ID, but it got stepped on. If we're going to let people try things and see if they work, and standardize real work, could be really valuable. The consensus at the meeting was to accept these drafts as WG work items; acceptance will be confirmed on the WG mailing list. Bulk DHCPv4 Lease Query --------------------------------------------------------------------- The consensus at the meeting was to accept this draft as a WG work item; acceptance will be confirmed on the WG mailing list. DHCP options for Access Point Name and attach type indication ------------------------------------------------------------- Jari: Where does this work belong? Authors and WG chairs will work together to find a home for the work. Bernie: better in mip6? John: have you presented elsewhere? There may be a parent wg that is aligned with your tech, and you would consult us for details around the actual protocol, so we're going to talk to Jari and see if there's a WG for which this would be appropriate. Raj: Ralph has looked at NetLMM Ralph: I appreciate the compliment, but our model of operation is that options like this that are not fundamental to operation of protocol have to come from parent wg that has requirement for the option; our job is to provide input to make sure the option is compatible with DHCP architecture and options guidelines. Bernie: are these options always expected to appear together? Would a mobile node ever send just APN? [yes] In that case is there a presumed attachment type? Raj: By default, the access network will assume it is an initial network entry unless it has other information from another access router. Bernie: might want to simplify other option, maybe all you need to say is here's the APN as one option, and this is a handoff as opposed to non-handoff. John: Should this option carry a name or an IP address? Alper: you referred to APN which is a 3GPP term, but this draft also applies to WiMAX, terminal can select attaching to visited CSM vs. home CSM. So its applicability goes beyond what the terminology suggests. It also applies to non-mobile IP scenarios: in WiMax we support mobile IP and non-mobile-IP attachment, which still needs network selection. ??: why not use old solution Raj: when you already have l2 mechanism you can use that, but there are other technologies, e.g. Wifi which doesn't have capability at Mac layer to send APN info. In such scenarios you would indicate home agent, you have to do at higher layer, in this case DHCP. ??: more applicable to wifi? Raj: applicable to generic networks which do not have this capability at l2. [additional discussion elided] Ralph: this is why this option needs to be presented elsewhere. Service Identfiers Option for DHCPv6 ---------------------------------------------------------------------------- Observation by several sources: this seems to be out of scope for the WG. Need to talk after the WG meeting to discover exactly what the motivation is, what the customer WG might be, whether the work belongs here. Scenario and Solution: Simple IP Multi-homing of the Host --------------------------------------------------------- Ralph: the IPv6 side of this should go to 6man, probably. Ted: Regarding IPv4, it's not clear whether the dhc WG is qualified to comment on this on a technical level in terms of routing. Ralph: will talk to ADs. Hiu: Jari allowed to present here to get feedback. Bernie: seems to me a respin of RFC3442, which is the classless static routing option, except this adds ToS. Jari, John, Ralph, Hui will discuss where the work belongs Guidelines for Creating New DHCP Options ------------------------------------------------------------------------------ Ted: provided comments to list (wordsmithing) Consensus at the meeting is that the draft is ready for WG last call. DHCPINFORM Message Clarifications ------------------------------------------------------------------------ Kim: I think clarifying this is a good idea. I'm sure I don't agree exactly with what's written here. E.g., I don't recall any place where we've looked at the source address of the DHCP packet, and I wouldn't start now. Or at least I'd think really hard before we start. Questions about where we send it back to are a good idea, I don't think the current list is correct. It's going to take some work, I think it's worth it. Hui: There is work on home network configuration using DHCPINFORM, I support this work item, should I wait for it to finish? Ralph: The nature of the draft that you're writing, does it overlap the clarifications that are in this draft? I don't understand where there might be a conflict. Hui: don't see conflict, just using DHCPINFORM. Ralph: you're using it in draft in other WG. Hiu: yes, to get configuration information for home network. Ralph: that would be a good thing for us to look at here. The consensus at the meeting was to accept this draft as a WG work item; acceptance will be confirmed on the WG mailing list. Dynamic Host Configuration Protocol Option for Softwires -------------------------------------------------------- Ted: shutting off DHCPv4 is a potential DoS attack. Bernie: otherwise the option looks good. Ted: really think you should just take out the thing about stopping the DHCPv4 state machine. Raj: is there a threat model that exists somewhere? Explains the why you would potentially have in-band security for DHCP? Alper: there's a threat analysis draft that talked about that, but it expired years ago. Ralph: history, we decided to do threat analysis, got a reasonable way in, but didn't finish and didn't publish. It's a draft of a threat analysis, but if I remember final state, it was useful. Paul Selkirk (ISC): presence of softwire option implies no IPv4? Ted: if you have a network where you don't want IPv4, just don't set up DHCPv4 server. This draft will be considered as a softwire WG work item. Bootstrapping RFC 3118 ---------------------------------- Stefan: is operating wifi roaming, and is very interested in seeing this draft move forward. It is possible to rely on layer 1/2 security, but for universities we want people to communicate, so these measures are not always appropriate. Restina Foundation, etee (sic) roaming consortium. Stig Venaas: I agree with what Stefan said, but I'm involved in same consortium. Could be quite good as way to get 3118 deployed. In addition to security in L2, could give a touch of binding between identity and IP address which some people are interested in. Joe Salowey: we think approaches are similar, could merge. Alper: going back to Raj's question, today there are various DHCP deployments where L1 and L2 endpoints don't match DHCP endpoints, in WiMax we are looking at running DHCP server not in local network but some other operator's network. When there's such a mismatch, embedding DHCP security becomes more essential. L1 and L2 endpoints are not in a position to ensure security for signaling that goes beyond their own domain. Raj: agree that there are potential scenarios like that. But there should be transitive trust. Alper: not as good. Ted: would love to see this go forward. Bernie: V6 as well? Alper: yes. we didn't mean to make a distinction between v4 and v6, but RFC3118 is v4-only. Bernie: when you respin, make it clear that these documents apply to both RFC 3118 and RFC 3315. Alper: will do. Ralph: Joe: you've already discussed merge with Alper, is that a way forward? Joe: I think that would be excellent. Alper: agree. Ralph: okay, we formally request that you do so, once we see draft we'll review for taking on as WG work item, hope that we can review that at next IETF. Ralph: we're done. Wrap-up ------- Alper: what happened to DHCP EAP over DHCP? John: we the analysis team where we stand is we're slightly behind on delivering the analysis to ADs and WG, our plan right now is based on the feedback of the conversation with WG meeting in Dublin, we'll prepare draft based on preliminary analysis. During DUblin gave feedback to author, expectation was that there would be a revision, I haven't seen one. If one comes out, then we'll have to respin the analysis to make sure that initial feedback is valid still. Alper: is there going to be a draft? What's the format? I presume draft, since there's no January meeting. John: team has targeted based on January, assumption is it would be in draft format and ultimately shared with WG. Alper: good. --Apple-Mail-1726--805590616 Content-Disposition: attachment; filename=minutes.txt Content-Type: text/plain; x-mac-creator=454D4178; x-unix-mode=0644; name="minutes.txt" Content-Transfer-Encoding: 7bit DHC Working group Thursday, November 20, 2008 Thanks to Ted Lemon for taking notes at the meeting, on which these minutes are based. [Agenda] Alper asked about the DHC Auth analysis. John will give status update. [DHC WG I-D status] draft-ietf-dhc-subnet-alloc --------------------------- Richard Johnson is confused because there were comments on subnet alloc draft which he hasn't addressed yet, he thinks he needs to do a revision before it goes to IESG. They were mostly nitpicks, he says. Ralph: let's take a note of that and deal with that offline. draft-ietf-dhc-vpn-option ------------------------- Kim Kinnear: I revised the draft based on the comments in the previous previous last call, there were only one set of minor comments from Bernie that said we didn't have to do anything about them, I figured I'd fold them in if there were any other comments from last call, they were mostly textual. I think it's ready for review now. Ralph: didn't get enough review last time. Bernie Volz agreed to review the draft. Ted agreed to do it; you'd better hassle him about it later. David Hankins also agreed to review the draft, in absentia. Kim: what we have now is ready for review, there are three textual comments, one minor possible misunderstanding, I'm sure there will be other similar comments, so not planning to review the draft again until this review is complete. draft-ietf-dhc-dhcpv6-reconfigure-rebind ---------------------------------------- Bernie, Richard and Ted Lemon agreed to review during a new WG last call. draft-ietf-dhc-relay-id-suboption --------------------------------- Bernie, Kim and Ted agreed to review during a new WG last call. draft-ietf-dhc-l2ra, draft-miles-dhc-dhcpv6-ldra ------------------------------------------------ These two drafts need to be correlated so that boilerplate describing problem space is the same or similar, even though mechanisms are different. Ralph is asking everyone to read the docs together so that we can discuss on mailing list. Ralph will kick off discussion. DHCP Auth analysis ------------------ John reports that we're slightly behind schedule. The review team has completed its preliminary review/analysis, and is currently planning on giving a draft version of that analysis to Jari Arkko (dhc WG Internet AD) in January. At that point the review team is going to determine the next step based on whether we get a revised version of the draft. We want to make sure the analysis we do is accurate with respect to the new revision. [Reviews of dhc WG I-Ds] DHCPv6 Remote Boot Options --------------------------------------------------------------------------- Vincent Zimmer from Intel. He's working on EFI in the UEFI forum. PXE is evolving within UEFI, and the latest UEFI spec has IPv6. Problem: what will the boot paradigm scenarios look like on IPv6? We can define APIs but on the wire we felt it was best to come to the IETF and work those. Question: Who will manage the "processor architecture type"? Make it an expert-reviewed IANA managed list. DHCPv6 option for network boot --------------------------------------------------------------------- (no presentation) Discussion of previous two drafts: Question for the group: how should the authors of the two drafts work together? Bernie: Is the next-server option was a good idea given that the URI option already contains that info? Ted: Is the PXE stuff was driving idiosyncracies in the protocol. Ralph wants them to try to reconcile the two drafts offline. DHCPv4 Vendor-specific Message , DHCP Vendor-specific Message ------------------------------------------------------------------------ Both drafts were dsicussed together. Kim: Leasequery had a message ID, but it got stepped on. If we're going to let people try things and see if they work, and standardize real work, could be really valuable. The consensus at the meeting was to accept these drafts as WG work items; acceptance will be confirmed on the WG mailing list. Bulk DHCPv4 Lease Query --------------------------------------------------------------------- The consensus at the meeting was to accept this draft as a WG work item; acceptance will be confirmed on the WG mailing list. DHCP options for Access Point Name and attach type indication ------------------------------------------------------------- Jari: Where does this work belong? Authors and WG chairs will work together to find a home for the work. Bernie: better in mip6? John: have you presented elsewhere? There may be a parent wg that is aligned with your tech, and you would consult us for details around the actual protocol, so we're going to talk to Jari and see if there's a WG for which this would be appropriate. Raj: Ralph has looked at NetLMM Ralph: I appreciate the compliment, but our model of operation is that options like this that are not fundamental to operation of protocol have to come from parent wg that has requirement for the option; our job is to provide input to make sure the option is compatible with DHCP architecture and options guidelines. Bernie: are these options always expected to appear together? Would a mobile node ever send just APN? [yes] In that case is there a presumed attachment type? Raj: By default, the access network will assume it is an initial network entry unless it has other information from another access router. Bernie: might want to simplify other option, maybe all you need to say is here's the APN as one option, and this is a handoff as opposed to non-handoff. John: Should this option carry a name or an IP address? Alper: you referred to APN which is a 3GPP term, but this draft also applies to WiMAX, terminal can select attaching to visited CSM vs. home CSM. So its applicability goes beyond what the terminology suggests. It also applies to non-mobile IP scenarios: in WiMax we support mobile IP and non-mobile-IP attachment, which still needs network selection. ??: why not use old solution Raj: when you already have l2 mechanism you can use that, but there are other technologies, e.g. Wifi which doesn't have capability at Mac layer to send APN info. In such scenarios you would indicate home agent, you have to do at higher layer, in this case DHCP. ??: more applicable to wifi? Raj: applicable to generic networks which do not have this capability at l2. [additional discussion elided] Ralph: this is why this option needs to be presented elsewhere. Service Identfiers Option for DHCPv6 ---------------------------------------------------------------------------- Observation by several sources: this seems to be out of scope for the WG. Need to talk after the WG meeting to discover exactly what the motivation is, what the customer WG might be, whether the work belongs here. Scenario and Solution: Simple IP Multi-homing of the Host --------------------------------------------------------- Ralph: the IPv6 side of this should go to 6man, probably. Ted: Regarding IPv4, it's not clear whether the dhc WG is qualified to comment on this on a technical level in terms of routing. Ralph: will talk to ADs. Hiu: Jari allowed to present here to get feedback. Bernie: seems to me a respin of RFC3442, which is the classless static routing option, except this adds ToS. Jari, John, Ralph, Hui will discuss where the work belongs Guidelines for Creating New DHCP Options ------------------------------------------------------------------------------ Ted: provided comments to list (wordsmithing) Consensus at the meeting is that the draft is ready for WG last call. DHCPINFORM Message Clarifications ------------------------------------------------------------------------ Kim: I think clarifying this is a good idea. I'm sure I don't agree exactly with what's written here. E.g., I don't recall any place where we've looked at the source address of the DHCP packet, and I wouldn't start now. Or at least I'd think really hard before we start. Questions about where we send it back to are a good idea, I don't think the current list is correct. It's going to take some work, I think it's worth it. Hui: There is work on home network configuration using DHCPINFORM, I support this work item, should I wait for it to finish? Ralph: The nature of the draft that you're writing, does it overlap the clarifications that are in this draft? I don't understand where there might be a conflict. Hui: don't see conflict, just using DHCPINFORM. Ralph: you're using it in draft in other WG. Hiu: yes, to get configuration information for home network. Ralph: that would be a good thing for us to look at here. The consensus at the meeting was to accept this draft as a WG work item; acceptance will be confirmed on the WG mailing list. Dynamic Host Configuration Protocol Option for Softwires -------------------------------------------------------- Ted: shutting off DHCPv4 is a potential DoS attack. Bernie: otherwise the option looks good. Ted: really think you should just take out the thing about stopping the DHCPv4 state machine. Raj: is there a threat model that exists somewhere? Explains the why you would potentially have in-band security for DHCP? Alper: there's a threat analysis draft that talked about that, but it expired years ago. Ralph: history, we decided to do threat analysis, got a reasonable way in, but didn't finish and didn't publish. It's a draft of a threat analysis, but if I remember final state, it was useful. Paul Selkirk (ISC): presence of softwire option implies no IPv4? Ted: if you have a network where you don't want IPv4, just don't set up DHCPv4 server. This draft will be considered as a softwire WG work item. Bootstrapping RFC 3118 ---------------------------------- Stefan: is operating wifi roaming, and is very interested in seeing this draft move forward. It is possible to rely on layer 1/2 security, but for universities we want people to communicate, so these measures are not always appropriate. Restina Foundation, etee (sic) roaming consortium. Stig Venaas: I agree with what Stefan said, but I'm involved in same consortium. Could be quite good as way to get 3118 deployed. In addition to security in L2, could give a touch of binding between identity and IP address which some people are interested in. Joe Salowey: we think approaches are similar, could merge. Alper: going back to Raj's question, today there are various DHCP deployments where L1 and L2 endpoints don't match DHCP endpoints, in WiMax we are looking at running DHCP server not in local network but some other operator's network. When there's such a mismatch, embedding DHCP security becomes more essential. L1 and L2 endpoints are not in a position to ensure security for signaling that goes beyond their own domain. Raj: agree that there are potential scenarios like that. But there should be transitive trust. Alper: not as good. Ted: would love to see this go forward. Bernie: V6 as well? Alper: yes. we didn't mean to make a distinction between v4 and v6, but RFC3118 is v4-only. Bernie: when you respin, make it clear that these documents apply to both RFC 3118 and RFC 3315. Alper: will do. Ralph: Joe: you've already discussed merge with Alper, is that a way forward? Joe: I think that would be excellent. Alper: agree. Ralph: okay, we formally request that you do so, once we see draft we'll review for taking on as WG work item, hope that we can review that at next IETF. Ralph: we're done. Wrap-up ------- Alper: what happened to DHCP EAP over DHCP? John: we the analysis team where we stand is we're slightly behind on delivering the analysis to ADs and WG, our plan right now is based on the feedback of the conversation with WG meeting in Dublin, we'll prepare draft based on preliminary analysis. During DUblin gave feedback to author, expectation was that there would be a revision, I haven't seen one. If one comes out, then we'll have to respin the analysis to make sure that initial feedback is valid still. Alper: is there going to be a draft? What's the format? I presume draft, since there's no January meeting. John: team has targeted based on January, assumption is it would be in draft format and ultimately shared with WG. Alper: good. --Apple-Mail-1726--805590616 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-1726--805590616-- From dhcwg-bounces@ietf.org Mon Dec 8 09:38:27 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCF23A6A71; Mon, 8 Dec 2008 09:38:27 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEC93A6A7F for ; Mon, 8 Dec 2008 09:38:25 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA18TVNBy8vu for ; Mon, 8 Dec 2008 09:38:24 -0800 (PST) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by core3.amsl.com (Postfix) with ESMTP id 714F93A67F1 for ; Mon, 8 Dec 2008 09:38:24 -0800 (PST) Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mB8Gpi9J010443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 12:38:01 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-179.cs.dartmouth.edu [129.170.212.179] by newblitzen.Dartmouth.EDU (Mac) via SMTP for id <138013009>; 08 Dec 2008 12:38:00 -0500 Message-ID: <493D5B77.1050708@Dartmouth.edu> Date: Mon, 08 Dec 2008 12:37:59 -0500 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Ralph Droms References: <4935915E.1060708@Dartmouth.edu> In-Reply-To: X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-From: massimiliano.pala@dartmouth.edu Cc: DHC-WG , Damien Neil Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0590387725==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0590387725== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000604030404060101020307" This is a cryptographically signed message in MIME format. --------------ms000604030404060101020307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ralph and Damien, thanks for the input, it is very useful. I was trying to take a look at how to define the options for the example, I picked the ip-address as, from the man page, you can specify a list of ip-address but it does not say IPv4 only (although there is an ipv6-address...). Shall I use the domain-list data type as specified in RFC 3361 section 3.1 instead ? Would this be a better encoding ? My idea is to use an already-existing data-type so it would be easier for PRQP adopters. Cheers, Max Ralph Droms wrote: > I agree with Damien's review. Take a look at RFC 4280 for an example of > how to write parallel definitions for an option in DHCPv4 and DHCPv6. > > - Ralph > > On Dec 2, 2008, at Dec 2, 2008,3:11 PM, Damien Neil wrote: > >> On Dec 2, 2008, at 11:49 AM, Massimiliano Pala wrote: >>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt >>> >>> I would need the expertise from your WG to validate the DHCP part of >>> the I-D. >> >> At first glance, two issues jump out at me: >> >> Section B.1.1 does not indicate whether the option is for DHCPv4 or >> DHCPv6. The option code and length fields are 16 bits wide, which >> implies DHCPv6, but the examples in subsequent sections imply DHCPv4. >> DHCPv4 options encode the option code and length as a single octet >> each. (Section B.1.1 also references RFC 3315, implying DHCPv6.) >> >> Section B.1.1 specifies that the option contains a list of DNS names, >> but the ISC DHCP examples in section B.1.2 are for an option >> containing a list of IPv4 addresses. >> >> - Damien >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Best Regards, Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] Massimiliano.Pala@dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov --------------ms000604030404060101020307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjA4 MTczNzU5WjAjBgkqhkiG9w0BCQQxFgQUX6yvZmKIcoaL5uic7sU/8r2BelUwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYCGarvcF8klSCqQB7f1odWFwLtjnlPZ3hikM/mEyCgjn2peTgdrjSUIhEz3hF45Ky74k42+ 5M+nX1ieg95nDgkQvRb7yudfIWCHz314bS+e+meC58uhVoLYhPzzUuKkXikBvh63cskjbXu1 ZsuG7xMYvBKdVrd+6IygGJP71tnutwAAAAAAAA== --------------ms000604030404060101020307-- --===============0590387725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0590387725==-- From dhcwg-bounces@ietf.org Mon Dec 8 10:29:25 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B41228C149; Mon, 8 Dec 2008 10:29:25 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AC028C149 for ; Mon, 8 Dec 2008 10:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwTFwXorz0an for ; Mon, 8 Dec 2008 10:29:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6857428C13B for ; Mon, 8 Dec 2008 10:29:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,736,1220227200"; d="scan'208";a="30360093" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2008 18:29:17 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB8ITHt0015485; Mon, 8 Dec 2008 13:29:17 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB8ITHtE000809; Mon, 8 Dec 2008 18:29:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 13:29:17 -0500 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 13:29:17 -0500 Message-Id: <52028AF8-6F1E-430A-8A52-19ECEE1ADDD6@cisco.com> From: Ralph Droms To: Massimiliano Pala In-Reply-To: <493D5B77.1050708@Dartmouth.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 13:29:16 -0500 References: <4935915E.1060708@Dartmouth.edu> <493D5B77.1050708@Dartmouth.edu> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Dec 2008 18:29:17.0064 (UTC) FILETIME=[E0D74080:01C95962] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3167; t=1228760957; x=1229624957; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20PKIX=20WG=20new=20I-D=20draft =3A=20DHCP=20section=20review |Sender:=20 |To:=20Massimiliano=20Pala=20; bh=5lcvwfnWrDtVy3JWmLzJhYQME2SvO+7IwA8+9Ch0waY=; b=Dwzm8yIeSOTsQjb6smzQacmW9CQHFbImSoIfiagkK1EjyQo0g7MFza5L+z gXhYT1g/9w2sFkHlhJQkPkz0ZVW6c3NbnAlZ/Q766gJAJZFhhj27OVhmSr9X 5JetHj2KGU; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: DHC-WG , Damien Neil , Ralph Droms Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org You could choose either IP addresses or FQDNs for the option payload. But, you'll still have to define both DHCPv4 and DHCPv6 versions of the option. You might want to look at http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03.txt - Ralph On Dec 8, 2008, at Dec 8, 2008,12:37 PM, Massimiliano Pala wrote: > Hi Ralph and Damien, > > thanks for the input, it is very useful. I was trying to take a look > at how to define the options for the example, I picked the ip-address > as, from the man page, you can specify a list of ip-address but it > does not say IPv4 only (although there is an ipv6-address...). > > Shall I use the domain-list data type as specified in RFC 3361 section > 3.1 instead ? Would this be a better encoding ? My idea is to use an > already-existing data-type so it would be easier for PRQP adopters. > > Cheers, > Max > > > Ralph Droms wrote: >> I agree with Damien's review. Take a look at RFC 4280 for an >> example of how to write parallel definitions for an option in >> DHCPv4 and DHCPv6. >> - Ralph >> On Dec 2, 2008, at Dec 2, 2008,3:11 PM, Damien Neil wrote: >>> On Dec 2, 2008, at 11:49 AM, Massimiliano Pala wrote: >>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt >>>> >>>> I would need the expertise from your WG to validate the DHCP part >>>> of the I-D. >>> >>> At first glance, two issues jump out at me: >>> >>> Section B.1.1 does not indicate whether the option is for DHCPv4 >>> or DHCPv6. The option code and length fields are 16 bits wide, >>> which implies DHCPv6, but the examples in subsequent sections >>> imply DHCPv4. DHCPv4 options encode the option code and length as >>> a single octet each. (Section B.1.1 also references RFC 3315, >>> implying DHCPv6.) >>> >>> Section B.1.1 specifies that the option contains a list of DNS >>> names, but the ISC DHCP examples in section B.1.2 are for an >>> option containing a list of IPv4 addresses. >>> >>> - Damien >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > > -- > > Best Regards, > > Massimiliano Pala > > -- > o > ------------------------------------------------------------------------ > Massimiliano Pala [OpenCA Project Manager] Massimiliano.Pala@dartmouth.edu > project.manager@openca.org > > Dartmouth Computer Science Dept Home Phone: +1 (603) > 369-9332 > PKI/Trust Laboratory Work Phone: +1 (603) > 646-9179 > -- > o > ------------------------------------------------------------------------ > > People who think they know everything are a great annoyance to those > of us > who do. > -- Isaac Asimov > _______________________________________________ > 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 dhcwg-bounces@ietf.org Mon Dec 8 14:20:06 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A87A3A6A9D; Mon, 8 Dec 2008 14:20:06 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF753A6A9D for ; Mon, 8 Dec 2008 14:20:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM6F5dvYlBfz for ; Mon, 8 Dec 2008 14:20:04 -0800 (PST) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by core3.amsl.com (Postfix) with ESMTP id 2D08B3A6833 for ; Mon, 8 Dec 2008 14:20:03 -0800 (PST) Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mB8MC1pY019217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 17:19:47 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-179.cs.dartmouth.edu [129.170.212.179] by newblitzen.Dartmouth.EDU (Mac) via SMTP for id <138037550>; 08 Dec 2008 17:19:45 -0500 Message-ID: <493D9D81.4090301@Dartmouth.edu> Date: Mon, 08 Dec 2008 17:19:45 -0500 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Ralph Droms References: <4935915E.1060708@Dartmouth.edu> <493D5B77.1050708@Dartmouth.edu> <52028AF8-6F1E-430A-8A52-19ECEE1ADDD6@cisco.com> In-Reply-To: <52028AF8-6F1E-430A-8A52-19ECEE1ADDD6@cisco.com> X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-From: massimiliano.pala@dartmouth.edu Cc: DHC-WG , Damien Neil Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0555256779==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0555256779== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060902050302010905090500" This is a cryptographically signed message in MIME format. --------------ms060902050302010905090500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ralph, that was kinda not clear to me - I thought that I did not need to define two different options for DHCPv4 and DHCPv6. I just uploaded the new version of the draft where I defined the PRQP server option for DHCPv4 and DHCPv6. The new draft is published as: http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-02.txt Please let me know what you think of this new version and if I successfully addressed your concerns :D Cheers, Max Ralph Droms wrote: > You could choose either IP addresses or FQDNs for the option payload. > But, you'll still have to define both DHCPv4 and DHCPv6 versions of the > option. > > You might want to look at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03.txt --------------ms060902050302010905090500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjA4 MjIxOTQ1WjAjBgkqhkiG9w0BCQQxFgQU39cOxbHkUjmDZkqgkKysZ6a+kq4wUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYCS/g5nFNgkKu4n2QGxio9Ga9+Xc4i77PlMYGC6vXYVOpuceUQjZDJ7cYDD4YDFaWKPhAeF YjgiM7REmzmhSyATNltwJ5v9hZYi3KFuBhojzQpczj+06BX0NBO8/2EOIvUuvIV9EIahJVyj 9NQTpznB9MiJQrKSKfCB2GFuj6c7mAAAAAAAAA== --------------ms060902050302010905090500-- --===============0555256779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0555256779==-- From dhcwg-bounces@ietf.org Mon Dec 8 20:26:14 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FBB3A696A; Mon, 8 Dec 2008 20:26:14 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118443A696A for ; Mon, 8 Dec 2008 20:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw7L5AmtGqun for ; Mon, 8 Dec 2008 20:26:12 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 343563A68C7 for ; Mon, 8 Dec 2008 20:26:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,739,1220227200"; d="scan'208";a="112795783" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2008 04:26:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB94Q6sN014062 for ; Mon, 8 Dec 2008 20:26:06 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB94Q6Se014415 for ; Tue, 9 Dec 2008 04:26:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 23:26:05 -0500 Received: from bxb-rdroms-8712.cisco.com ([10.98.10.83]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 23:26:05 -0500 Message-Id: From: Ralph Droms To: DHC-WG WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 23:25:59 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 09 Dec 2008 04:26:05.0687 (UTC) FILETIME=[40718070:01C959B6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=675; t=1228796767; x=1229660767; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Drafts=20to=20accept=20as=20WG=20work=20items |Sender:=20; bh=JtaxEFL/pMalFxRijyso8P3KVQ0JEgb3XkgoAhoZ7lA=; b=LJMUf8NuD4xUwwAtBqK/zy12OM/frxoTXe0hN8F18czKX0Ixjlla3fFriZ 3PYNeaDzu3W9dA14fS0RARDVx8bwdT3ouMyEbWEL5zk65KwicS0bTQ3QBHx4 vbupkx4GcfbH8HQjOtBWDYYjinEeLs5WSeufXAzaGTbyUTGyf5fKc=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [dhcwg] Drafts to accept as WG work items X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org During the recent dhc WG meeting in Minneapolis, the WG reviewed several documents for acceptance as WG work items. The consensus at the meeting was to accept these documents; this consensus now needs to be confirmed o nthe WG mailing list. If there are any objections to accepting the following Internet Drafts as WG work items, please respond to the mailing list by 1700PST, Friday, Dec 12. draft-volz-dhc-dhcpv4-vendor-message-00 draft-volz-dhc-dhcpv6-vendor-message-01 draft-kinnear-dhc-dhcpv4-bulk-leasequery-01 draft-dhankins-dhcpinform-clarify-00 If there are no objections by Friday, these drafts will become WG work items. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From maureen.mckay@afhe.ualberta.ca Tue Dec 9 00:35:15 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F091928C0F6 for ; Tue, 9 Dec 2008 00:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.284 X-Spam-Level: X-Spam-Status: No, score=-34.284 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4KWiG2yCLQM for ; Tue, 9 Dec 2008 00:35:15 -0800 (PST) Received: from 8-188.126-70.tampabay.res.rr.com (8-188.126-70.tampabay.res.rr.com [70.126.188.8]) by core3.amsl.com (Postfix) with SMTP id 7D81628C0EA for ; Tue, 9 Dec 2008 00:35:14 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081209083514.7D81628C0EA@core3.amsl.com> Date: Tue, 9 Dec 2008 00:35:14 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Tue Dec 9 03:20:32 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C993A6B0C; Tue, 9 Dec 2008 03:20:32 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2820B3A6B0C for ; Tue, 9 Dec 2008 03:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmnopNXOaMPw for ; Tue, 9 Dec 2008 03:20:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D88353A6AF3 for ; Tue, 9 Dec 2008 03:20:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,740,1220227200"; d="scan'208";a="30472224" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2008 11:20:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB9BKNMn006572 for ; Tue, 9 Dec 2008 06:20:23 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9BKNO7013644 for ; Tue, 9 Dec 2008 11:20:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 06:20:23 -0500 Received: from bxb-rdroms-8712.cisco.com ([10.98.10.83]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 06:20:23 -0500 Message-Id: From: Ralph Droms To: DHC-WG WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 06:20:12 -0500 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 09 Dec 2008 11:20:23.0159 (UTC) FILETIME=[20A6B870:01C959F0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5346; t=1228821623; x=1229685623; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20FW=3A=20I-D=20Action=3Adraft-ietf-geopriv-dhcp- lbyr-uri-option-03.txt |Sender:=20 |To:=20DHC-WG=20WG=20; bh=DmloERtUAw34hakp/2GUcb+A6BA4ZlwKLdYk1hVYWpM=; b=0ABOIwDe7rSqQnDooAxpZgdH1yD6whh4c4TKBNl1JxQVWYaWIwMP4qxcFZ 4DgmzEKndKP1Ayjz6L5CNY981B00YL0WN2ngLZtUszsKJmPI7H4v8PKYJxLX mVamBiTCPM; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [dhcwg] FW: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here's another draft the WG should review. I need to find a least one volunteer to read the DHCP-related portions of this draft and publish comments. - Ralph >>> ------ Forwarded Message >>> From: >>> Reply-To: >>> Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) >>> To: >>> Cc: >>> Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Geographic Location/Privacy Working >>> Group >>> of the IETF. >>> >>> >>> Title : Dynamic Host Configuration Protocol (DHCP) Option >>> for a >>> Location Uniform Resource Identifier (URI) >>> Author(s) : J. Polk >>> Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>> Pages : 11 >>> Date : 2008-11-03 >>> >>> This document creates a Dynamic Host Configuration Protocol (DHCP) >>> Option for the downloading of a Uniform Resource Identifier (URI) >>> pointing to the geolocation record of an endpoint. This URI, called >>> a Location-by-Reference (LbyR), points to a record on a location >>> server which tracks the geolocation of the endpoint. Once >>> downloaded by an endpoint, this LbyR can be forwarded to another >>> entity, to be dereferenced if this entity wants to learn the >>> geolocation of the sender endpoint. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- >>> 03.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. >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> ------ End of Forwarded Message >> >> >> >> James - I can't recall if your draft has been discussed in the dhc >> WG; I don't think it has. Depending on its current state, it would >> be a good idea to get a quick review now, as the WG will likely be >> asked to review it during any last calls. >> >> - Ralph >> >> Begin forwarded message: >> >>> From: "Ralph Droms (rdroms)" <rdroms@cisco.com >>> > >>> Date: November 3, 2008 8:16:49 PM EST >>> To: "DHC WG" <dhcwg@ietf.org> >>> Subject: [dhcwg] FW: I-DAction:draft-ietf-geopriv-dhcp-lbyr-uri- >>> option-03.txt >>> >>> Here's another draft the WG should review. >>> >>> - Ralph >>> ------ Forwarded Message >>> From: <Internet-Drafts@ietf.org> >>> Reply-To: <internet- >>> drafts@ietf.org> >>> Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) >>> To: <i-d-announce@ietf.org> >>> Cc: <geopriv@ietf.org> >>> Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Geographic Location/Privacy >>> Working Group >>> of the IETF. >>> >>> >>> Title : Dynamic Host Configuration Protocol (DHCP) >>> Option for a >>> Location Uniform Resource Identifier (URI) >>> Author(s) : J. Polk >>> Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>> Pages : 11 >>> Date : 2008-11-03 >>> >>> This document creates a Dynamic Host Configuration Protocol (DHCP) >>> Option for the downloading of a Uniform Resource Identifier (URI) >>> pointing to the geolocation record of an endpoint. This URI, called >>> a Location-by-Reference (LbyR), points to a record on a location >>> server which tracks the geolocation of the endpoint. Once >>> downloaded by an endpoint, this LbyR can be forwarded to another >>> entity, to be dereferenced if this entity wants to learn the >>> geolocation of the sender endpoint. >>> >>> A URL for this Internet-Draft is: >>> >> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- >>> 03.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. >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> ------ End of Forwarded Message >> >> > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 9 18:58:21 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA76F3A6B78; Tue, 9 Dec 2008 18:58:21 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEC73A6B61 for ; Tue, 9 Dec 2008 18:58:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZWSJAXC+Eo7 for ; Tue, 9 Dec 2008 18:58:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CF9703A6806 for ; Tue, 9 Dec 2008 18:58:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,744,1220227200"; d="scan'208";a="30565983" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Dec 2008 02:58:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBA2wCWl021072 for ; Tue, 9 Dec 2008 21:58:12 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBA2wCga029789 for ; Wed, 10 Dec 2008 02:58:12 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 21:58:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 21:54:32 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109E4323D@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <3FB6A7DB-3BF8-4610-A7D3-0C3B1EB86975@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt Thread-Index: AclXHOWFwncSfUoaS2aT3bpUsOCSCADVadfA References: <3FB6A7DB-3BF8-4610-A7D3-0C3B1EB86975@cisco.com> From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , "Dhcwg WG" X-OriginalArrivalTime: 10 Dec 2008 02:58:12.0676 (UTC) FILETIME=[23E5A040:01C95A73] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1745; t=1228877892; x=1229741892; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=2 0draft-ietf-dhc-relay-id-suboption-04.txt |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =20=22Dhcwg=20WG=22=20; bh=O5zHfBgKnRz7PxtIlwrol0lbLU1EAwNFjMAmjOQKSKY=; b=fnu9AwmJT/NJA4Xj7toD0crZS2jqhZZzpZMX4SJ+TxvPcMOm9Sn4Q4J9Jm yBZ0wK9gErbqYlCVIfg8oozLvosUDWpI+F5/eWQ10JRXYQ5NmqVuFo3YEkJI HtqN7BPEio; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I support this draft moving forward "as is". - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Friday, December 05, 2008 4:03 PM To: Dhcwg WG Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt This message announces a WG last call on "The DHCPv4 Relay Agent Identifier Suboption" . The last call will conclude at 1700PDT on December 19, 2008. This document is intended for publication as a Proposed Standard. The -04 revision of the document includes changes based on the comments received during the previous last call. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-relay-id-suboption-04.txt defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a unique identifier configured or generated at the relay agent. The suboption allows a DHCP relay agent to include the unique identifier in the DHCP messages it sends. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04 .txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ 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 dhcwg-bounces@ietf.org Tue Dec 9 19:06:23 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF8C3A68D3; Tue, 9 Dec 2008 19:06:23 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9F13A68D3 for ; Tue, 9 Dec 2008 19:06:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9zrqQNkxPYa for ; Tue, 9 Dec 2008 19:06:21 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AE5F13A6806 for ; Tue, 9 Dec 2008 19:06:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,744,1220227200"; d="scan'208";a="30566534" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Dec 2008 03:06:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBA36F8Q023810; Tue, 9 Dec 2008 22:06:15 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBA36FWC001597; Wed, 10 Dec 2008 03:06:15 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 22:06:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 22:05:50 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109E4323F@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <493D9D81.4090301@Dartmouth.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] PKIX WG new I-D draft: DHCP section review Thread-Index: AclZgx5Mqqi86VN2TH+29WBJrvGlHgA7/ZBg References: <4935915E.1060708@Dartmouth.edu><493D5B77.1050708@Dartmouth.edu><52028AF8-6F1E-430A-8A52-19ECEE1ADDD6@cisco.com> <493D9D81.4090301@Dartmouth.edu> From: "Bernie Volz (volz)" To: "Massimiliano Pala" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 10 Dec 2008 03:06:15.0735 (UTC) FILETIME=[43D29470:01C95A74] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2117; t=1228878375; x=1229742375; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20PKIX=20WG=20new=20I-D=20draft =3A=20DHCP=20section=20review |Sender:=20 |To:=20=22Massimiliano=20Pala=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdr oms)=22=20; bh=z8J/s/5N4g3ZJhX685Yt3cpPzJ0x3YYhTLYZkVAQBGw=; b=z4ZYpV8bTcKa0DE9b8//h7hYCKBP0KVWQPHCylBuvk2o3dwgNcyMQUBLPf ckLv05grbbSBm2O35px5kSSubDWWk9lyhM4gVkIHCkXVO9MZBQX3OqKfsOxw qPIdnbyQc0; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DHC-WG , Damien Neil Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org While the DHCP(v4+v6) option definitions are now much better (in 02), I wonder whether this will fly. Can new options be defined in an Appendix of an RFC? There's no IANA directives in the draft to request IANA to assign codes for these options? In fact: 5. IANA Considerations This document has no actions for IANA. Which is clearly wrong if new DHCP options are to be assigned? Also, while DHCPv6 has plenty of "available" option numbers, DHCPv4 doesn't have as many. I wonder whether if this is truly experimental, that a Vendor Specific Information Option (for both v4 + v6) might not be better? You would need to get an Enterprise-ID if you don't already have one. If all depends on how widely this is to be implemented (ie, how experimental is it?). If 'real' IANA assigned options are desired, the Appendix/IANA cosniderations issues are more likely for the AD to address? Or you might want to see what other Experimental RFCs have done in terms of new definitions for IANA maintained registries. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Massimiliano Pala Sent: Monday, December 08, 2008 5:20 PM To: Ralph Droms (rdroms) Cc: DHC-WG; Damien Neil Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review Hi Ralph, that was kinda not clear to me - I thought that I did not need to define two different options for DHCPv4 and DHCPv6. I just uploaded the new version of the draft where I defined the PRQP server option for DHCPv4 and DHCPv6. The new draft is published as: http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-02.txt Please let me know what you think of this new version and if I successfully addressed your concerns :D Cheers, Max Ralph Droms wrote: > You could choose either IP addresses or FQDNs for the option payload. > But, you'll still have to define both DHCPv4 and DHCPv6 versions of the > option. > > You might want to look at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03. txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 10 08:01:13 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5C33A6BC8; Wed, 10 Dec 2008 08:01:13 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96633A6BC8; Wed, 10 Dec 2008 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMgHYb4MHQoB; Wed, 10 Dec 2008 08:01:10 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BE81B3A6929; Wed, 10 Dec 2008 08:01:10 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D8502198782; Wed, 10 Dec 2008 18:01:03 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 6850B1986EF; Wed, 10 Dec 2008 18:01:03 +0200 (EET) Message-ID: <493FE7A7.30607@piuha.net> Date: Wed, 10 Dec 2008 18:00:39 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: dhcwg@ietf.org References: <20081020123425.2DA143A69B5@core3.amsl.com> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: ietf@ietf.org Subject: Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I wanted to send a message about my conclusion of this thread, as the draft is now progressing to IESG review. I sympathize with the desire to pull as much data as possible with a simple request and no prior knowledge of what sessions exist. I think it is obvious that with a better understanding of how to use SNMP, we can avoid the silliest approach to pulling data -- I hope there is a way to provide better education on how to use SNMP for something like this. But I'm not expert enough to say whether you can reach exactly an equivalent model as this draft has. Maybe. Nevertheless, it is clear to me that there is consensus in the WG to do this. They are chartered to do infrastructure improvements (such as this one) to DHCP. There are customers who need to do this. The last call discussion has raised alternative ways to implement this but no specific problems in the current approach. I believe that in this case we need to let the WG use the approach they have chosen. More generally, I believe that if there are specific data access needs in applications for large volume, bulk, etc -- the WGs in charge of those applications can choose the approach they want to use for the access to the data. While most of our management needs are fulfilled by MIBs, I do not think we can preclude other solutions for specialized situations, such as recovering DHCP session data. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From kieran@123games.dk Wed Dec 10 14:25:44 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4E128C1FA for ; Wed, 10 Dec 2008 14:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.628 X-Spam-Level: X-Spam-Status: No, score=-12.628 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmakzhqnGtfI for ; Wed, 10 Dec 2008 14:25:44 -0800 (PST) Received: from akzonobel.com (unknown [92.12.9.32]) by core3.amsl.com (Postfix) with SMTP id 1F8CB28C1F7 for ; Wed, 10 Dec 2008 14:25:42 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081210222543.1F8CB28C1F7@core3.amsl.com> Date: Wed, 10 Dec 2008 14:25:42 -0800 (PST)
Visit site now!

Visit our huge store



The announcement was widely speculated about and did notSgolne Royal, the candidate from the Socialist
 From kontakt@andreas-bist.de Thu Dec 11 00:59:49 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D9C3A6A5A for ; Thu, 11 Dec 2008 00:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.535 X-Spam-Level: **** X-Spam-Status: No, score=4.535 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DE=0.35, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47WQsAPxUcms for ; Thu, 11 Dec 2008 00:59:49 -0800 (PST) Received: from p549296A3.dip0.t-ipconnect.de (p549296A3.dip0.t-ipconnect.de [84.146.150.163]) by core3.amsl.com (Postfix) with SMTP id E0C343A6A5C for ; Thu, 11 Dec 2008 00:59:47 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211085947.E0C343A6A5C@core3.amsl.com> Date: Thu, 11 Dec 2008 00:59:47 -0800 (PST)
Visit site now!

Don't miss this opportunity!



"came home" to the Liberal and National Parties. He saidongoing nuclear programme.
 From mms361@alid.co.uk Thu Dec 11 07:55:34 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D5D3A6A1E for ; Thu, 11 Dec 2008 07:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.882 X-Spam-Level: X-Spam-Status: No, score=-17.882 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_PL=1.135, HELO_MISMATCH_PL=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t0IivXOpAZu for ; Thu, 11 Dec 2008 07:55:34 -0800 (PST) Received: from amrest.com.pl (unknown [86.126.61.166]) by core3.amsl.com (Postfix) with SMTP id E4B4E3A67D9 for ; Thu, 11 Dec 2008 07:55:32 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211155532.E4B4E3A67D9@core3.amsl.com> Date: Thu, 11 Dec 2008 07:55:32 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Thu Dec 11 12:07:33 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508633A6A62; Thu, 11 Dec 2008 12:07:33 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1299B3A6A62 for ; Thu, 11 Dec 2008 12:07:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7xty1n8bcpf for ; Thu, 11 Dec 2008 12:07:31 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 2AA613A6996 for ; Thu, 11 Dec 2008 12:07:31 -0800 (PST) Received: from david.isc.org (c-67-180-139-45.hsd1.ca.comcast.net [67.180.139.45]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBBK7P1c010025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 12:07:25 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 0973716E1A3; Thu, 11 Dec 2008 12:07:24 -0800 (PST) Date: Thu, 11 Dec 2008 12:07:24 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081211200724.GR6331@isc.org> References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300177792==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1300177792== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tk6xM/wkRlnXD2NA" Content-Disposition: inline --tk6xM/wkRlnXD2NA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 05, 2008 at 03:50:18PM -0500, Ralph Droms wrote: > This message announces a WG last call on "Virtual Subnet Selection > Options for DHCPv4 and DHCPv6" . I've reviewed this draft in the past, and I've reviewed the -09 revision which includes changes pursuant to my previous review (a whole section!). I'd like to say that I'm completely satisfied by the changes, they clarify and measure the context in which these new options are planned for use, and so I support acceptance of the document. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --tk6xM/wkRlnXD2NA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFJQXL8cXeLeWu2vmoRAltYAJ9E5MCj40vPS5VushxnvsMG9cs3wwCfWCVl 1Md0oDuNTx1LPRdOYFyc5IU= =Wodk -----END PGP SIGNATURE----- --tk6xM/wkRlnXD2NA-- --===============1300177792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1300177792==-- From dhcwg-bounces@ietf.org Thu Dec 11 14:03:42 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A96028C108; Thu, 11 Dec 2008 14:03:42 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0763A67AB; Thu, 11 Dec 2008 14:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7799oy2Tjh7r; Thu, 11 Dec 2008 14:03:40 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6FD053A66B4; Thu, 11 Dec 2008 14:03:40 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 055BE1986F9; Fri, 12 Dec 2008 00:03:34 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4CACB1986CE; Fri, 12 Dec 2008 00:03:33 +0200 (EET) Message-ID: <49418E1C.2030009@piuha.net> Date: Fri, 12 Dec 2008 00:03:08 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Mark Stapp References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> In-Reply-To: <49415B22.7070008@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , IESG , Lars Eggert Subject: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Authors, WG, I wanted to report on the status of this draft after tonight's IESG telechat. Everything else is in order, but Lars Eggert has a transport-related Discuss. Two issues were raised: First, he wants to put in some text to recommend against going lower than the current timeout values, as too frequent reconnection attempts or giving up too fast can interfere with the TCP's mechanisms and cause congestion or even make the application work slower than it would with TCP. This should be easy to do. Here's some suggested text: OLD: Implementations MAY make these values configurable. NEW: Implementations MAY make these values configurable. However, configuring too small timeout values may lead to harmful behavior both to this application as well as to other traffic in the network. As a result, timeout values smaller than the default values are NOT RECOMMENDED. The other issue relates to how the draft has specified timeout behavior for various stages of the protocol. I just had a long chat with Lars and we think we understand the situation better now (authors, please ignore previous e-mail on this topic). The high-level question we have is whether all this is necessary. For instance, the protocol includes retry attempts and timeouts for opening the connection. Or for maximum waiting time for blocking on the socket when sending the request. TCP will do all this for you. I'm not sure it is worthwhile to try again, if TCP cannot establish a connection. It already tried very hard. And if the request/response cannot be sent, TCP will eventually timeout. Specifying your own timeout behavior will involve some pain (more on this below). Why do we need to do that? Are we expecting that this application is special in the sense that its timeliness requirements are more stringent than TCP's? Are there current implementations, and do they do this? After a lengthy discussion with Lars, we think that your current scheme works. However, there are a few caveats that may or may not be obvious: By default, send(2) only blocks if the *socket buffer* is full, and this is not the same as TCP itself being stuck. The fact that you successfully used the system call to send a small number of bytes, for instance, does not imply that TCP is making progress. In the bulk leasequery protocol this would very likely happen for requests. The end result would be that you'd never block on request. If TCP had trouble getting the request to the server, you'd eventually timeout on waiting for the response. There are different ways to interpret the word "blocked" in the specification. Are we using it in the EAGAIN sense i.e., with non-blocking mode set, or simply in the sense of the send/write blocking? The latter would be incorrect. For instance, if the server sends a very large response with one call, it may take a while to transport everything. But TCP is still making progress, so it would seem to be inappropriate to fail just because you had a lot of data to send. Finally, behavior at the end of a response becomes interesting depending on whether or not the socket is closed. If you write some amount of data to the socket buffer, send/write succeeds but you don't actually know how long it takes to transport the data. You'll get an error if TCP fails, but that would be much later. You can do a blocking close call, however. But I do not know if the server even cares about whether the data went through... maybe it is enough that the client waits for all the data to arrive, and eventually gives up if it does not. If we decide to keep the timeout processing in the draft, some clarification regarding the above should probably be added. What do you want to do? Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From kissmarknn@360.cc Thu Dec 11 17:49:05 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A883A6AF6 for ; Thu, 11 Dec 2008 17:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dLzvuKwHt1z for ; Thu, 11 Dec 2008 17:49:05 -0800 (PST) Received: from 82-33-101-95.cable.ubr10.aztw.blueyonder.co.uk (82-33-101-95.cable.ubr10.aztw.blueyonder.co.uk [82.33.101.95]) by core3.amsl.com (Postfix) with SMTP id B9E4D3A6ABC for ; Thu, 11 Dec 2008 17:49:04 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212014904.B9E4D3A6ABC@core3.amsl.com> Date: Thu, 11 Dec 2008 17:49:04 -0800 (PST)
Visit site now!

From dhcwg-bounces@ietf.org Fri Dec 12 08:16:26 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1343A699A; Fri, 12 Dec 2008 08:16:26 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16E33A686D for ; Thu, 11 Dec 2008 17:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFllZ9KkqNJg for ; Thu, 11 Dec 2008 17:01:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C57C53A67EA for ; Thu, 11 Dec 2008 17:01:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,207,1228089600"; d="scan'208";a="30773605" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Dec 2008 01:01:42 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBC11fq9027937; Thu, 11 Dec 2008 20:01:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBC11fsL022774; Fri, 12 Dec 2008 01:01:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Dec 2008 20:01:41 -0500 Received: from kkinnear-wxp01.cisco.com ([10.86.249.12]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Dec 2008 20:01:40 -0500 Message-Id: <4.3.2.7.2.20081211195903.01932538@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Dec 2008 20:01:54 -0500 To: Alfred =?hp-roman8?B?SM5uZXM=?= , kkinnear@cisco.com, volz@cisco.com, nrussell@cisco.com, mjs@cisco.com, ramakrishnadtv@infosys.com, bharat_joshi@infosys.com, pavan_kurapati@infosys.com From: Kim Kinnear In-Reply-To: <200812120023.BAA23600@TR-Sys.de> Mime-Version: 1.0 X-OriginalArrivalTime: 12 Dec 2008 01:01:40.0842 (UTC) FILETIME=[3143ECA0:01C95BF5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=83; t=1229043701; x=1229907701; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20draft-kinnear-dhc-dhcpv4-bulk-leasequer y-01 |Sender:=20 |To:=20Alfred=20=3D?hp-roman8?B?SM5uZXM=3D?=3D=20,=20kkinnear@cisco.com,=0A=20=20=20=20=20=20=20=20volz@c isco.com,=20nrussell@cisco.com,=20mjs@cisco.com,=0A=20=20=20 =20=20=20=20=20ramakrishnadtv@infosys.com,=20bharat_joshi@in fosys.com,=0A=20=20=20=20=20=20=20=20pavan_kurapati@infosys. com; bh=OSurgJWpSW3udzpkBB7dT7+u/tEskS38yol80y/tTlM=; b=DBFYHxy+4VfSBiviJ6E9PthPyCYq4splgigiq8zU7uWJ1ZErkIwev1DdNS thjoD99IK6NvwDJ6/LFkhRkMyg3Uwg70kepRuf4POsxI3WDZRrfLzolW0cU4 +hRIk0vayx; Authentication-Results: rtp-dkim-1; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Fri, 12 Dec 2008 08:16:26 -0800 Cc: dhcwg@ietf.org, kkinnear@cisco.com Subject: Re: [dhcwg] draft-kinnear-dhc-dhcpv4-bulk-leasequery-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Alfred, Thank you for the review. I appreciate the input. Regards -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 12 08:16:39 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361873A6B00; Fri, 12 Dec 2008 08:16:39 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5EA28C124 for ; Thu, 11 Dec 2008 16:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.474 X-Spam-Level: * X-Spam-Status: No, score=1.474 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WcQdQjXMFUV for ; Thu, 11 Dec 2008 16:25:28 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 798F928C145 for ; Thu, 11 Dec 2008 16:25:26 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA024671425; Fri, 12 Dec 2008 01:23:45 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA23600; Fri, 12 Dec 2008 01:23:43 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200812120023.BAA23600@TR-Sys.de> To: kkinnear@cisco.com, volz@cisco.com, nrussell@cisco.com, mjs@cisco.com, ramakrishnadtv@infosys.com, bharat_joshi@infosys.com, pavan_kurapati@infosys.com Date: Fri, 12 Dec 2008 01:23:43 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Dec 2008 08:16:38 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] draft-kinnear-dhc-dhcpv4-bulk-leasequery-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org SGVsbG8sCmFmdGVyIHN0dWR5aW5nIHRoZSBJbnRlcm5ldC1EcmFmdCBhdXRob3JlZC9lZGl0ZWQg YnkgeW91LAogICAgICAgICAgZHJhZnQta2lubmVhci1kaGMtZGhjcHY0LWJ1bGstbGVhc2VxdWVy eS0wMSwKSSdkIGxpa2UgdG8gc3VibWl0IGEgZmV3IGNvbW1lbnRzLCBtb3N0bHkgYWRkcmVzc2lu ZyB0ZXh0dWFsCmZsYXdzIEkgZm91bmQgaW4gdGhhdCBtZW1vLgoKQmVzaWRlcyB0aGVzZSBmbGF3 cywgdGhlIGJhc2ljIGRlc2lnbiBzZWVtcyB0byBiZSBzb2xpZCwgYW5kIGl0cwpkZXNjcmlwdGlv biBpcyBjbGVhciBlbm91Z2ggdG8gYWxsb3cgaW5kZXBlbmRlbnQsIGludGVyb3BlcmFibGUKaW1w bGVtZW50YXRpb25zICdmcm9tIHNjcmF0Y2gnLgoKClRoZSBpdGVtcyBiZWxvdyBhcmUgcHJlc2Vu dGVkIGluIHRleHR1YWwgb3JkZXIuClRvIGdpdmUgbW9yZSBjb250ZXh0LCBzb21ldGltZXMgSSBx dW90ZSBsYXJnZXIgYmxvY2tzIG9mIHRleHQKbGl0ZXJhbGx5IGFuZCBzaG93IHRoZSByZXBsYWNl bWVudCBwcm9wb3NlZCB1c2luZyB0aGUgc2hvcnRoYW5kCm5vdGF0aW9uOgoKICAgPG9yaWdpbmFs IGRyYWZ0IHRleHQ+Ci0tLQogICA8bW9kaWZpZWQgdGV4dD4KCkkgdXNlIGNoYW5nZSBiYXJzICgn fCcgaW4gY29sdW1uIDEpIGFuZCBvY2Nhc2lvbmFsbHkKdXAvZG93biBwb2ludGluZyBtYXJrZXIg bGluZXMgKCdeXl4nLyd2dnYnKSB0byBlbXBoYXNpemUKdGhlIGxvY2F0aW9uIG9mIHRleHR1YWwg aXNzdWVzIGFuZC9vciBwcm9wb3NlZCBjb3JyZWN0aW9ucy4KTW9kaWZpZWQgdGV4dCBoYXMgYmVl biByZS1hZGp1c3RlZCB0byBtYXRjaCBSRkMgZm9ybWF0dGluZwpydWxlcywgd2hlcmUgYXBwcm9w cmlhdGUuICBJIGFsc28gdHJ5IHRvIGFjY29tb2RhdGUgcHVibGlzaGVkClJGQy1FZCBwb2xpY3kg b24gc3R5bGUgYW5kIHB1bmN0dWF0aW9uIGV0Yy4gaW4gbXkgcHJvcG9zYWxzLgoKCigxKSAgU2Vj dGlvbiAyLCBidWxsZXQgJ2Nsb2NrIHNrZXcnCgpFdmVuIE5UUCBjYW5ub3QgYXNzdXJlIHRoYXQg dGhlIGNsb2NrIHNrZXcgaXMgKnplcm8qLgpUaGVyZWZvcmUsIEkgc3VnZ2VzdCB0byByZXBsYWNl ICJ6ZXJvIiBieSAic21hbGwiIG9yICJuZWdsaWdpYmxlIi4KCihUaGlzIGlzc3VlIHJlY3VycyBp biBTZWN0aW9uIDguNC4pCgoKKDIpICBTZWN0aW9uIDMsIGJ1bGxldHMKClRoZXNlIGJ1bGxldHMg YXJlIGEgY29udGludWF0ZWQgZW51bWVyYXRpb24gb2YgcHJvcGVydGllcywKaW50cm9kdWNlZCBi eSB0aGUgaGVhZGxpbmUsCgogICBUaGUgZXhpc3RpbmcgcXVlcnkgdHlwZXMKCkNvbnNlcXVlbnRp YWxseSwgeW91IHN0YXJ0IHRoZSB0ZXh0IGluIGFsbCBmb3VyIGJ1bGxldHMgaW4gbG93ZXJjYXNl LgpIb3dldmVyLCB0aGUgZmlyc3QgdGhyZWUgYnVsbGV0cyBlbmQgd2l0aCBhIHBlcmlvZCwgYW5k IHRoZSBmaXJzdCBvbmUKZXZlbiBpcyBzZXBhcmF0ZWQgaW50byB0d28gc2VudGVuY2VzLiAgSG93 ZXZlciwgdGhlIGxhc3QgYnVsbGV0IGVuZHMKd2l0aG91dCBhbnkgb3VuY3R1YXRpb24uCgpUbyBh Y2hpZXZlIGNvbnNpc3RlbmN5IGluIGdyYW1tYXIvcHVuY3R1YXRpb24sIEkgcHJvcG9zZSB0byBy ZXBsYWNlCmFsbCBwZXJpb2RzIGluIHRoZSBmaXJzdCB0aHJlZSBidWxsZXRzIGJ5IHNlbWljb2xv bnMgYW5kIGFkZCBhIHRyYWlsaW5nCnBlcmlvZCB0byB0aGUgbGFzdCBidWxsZXQuCgoKKDMpICBT ZWN0aW9uIDQgLS0gaW1wcm92ZWQgd29yZGluZwoKVGhlIHByZXNlbnQgZHJhZnQgdGV4dCBjb250 YWlucyB0aGUgJ2FsdGVybmF0aXZlJywKICAgICAgIC4uLiBhbHNvIC4uLiAgIC4uLiBvciAuLi4K CkluIG9yZGVyIHRvIGJldHRlciBjbGFyaWZ5IHRoZSBsb2dpYyBvZiB0aGF0IGxvbmcgc2VudGVu Y2UsCkkgc3VnZ2VzdCB0byBzdXBwbHkgdGhlIHNvbWVob3cgbWlzc2luZyAiZWl0aGVyIiwgZ2l2 aW5nOgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbLi4uXS4gIFRoZQogICBtZWNoYW5pc20gc2hvdWxkIGFsc28gYWxsb3cgYW4gQWNjZXNz IENvbmNlbnRyYXRvciB0byByZXRyaWV2ZQp8ICBjb25zb2xpZGF0ZWQgSVAgYWRkcmVzcyBiaW5k aW5nIGluZm9ybWF0aW9uIGZvciBlaXRoZXIgdGhlIGVudGlyZQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eCiAgIGFjY2VzcyBjb25jZW50 cmF0b3Igb3IgZm9yIGEgc2luZ2xlIGNvbm5lY3Rpb24vY2lyY3VpdC4KCltUaGUgc2Vjb25kICJm b3IiIGluIHRoZSBsYXN0IGxpbmUgY291bGQgYmUgZHJvcHBlZCBhcyB3ZWxsCiBpbiB0aGlzIGNh c2UuXQoKCig0KSAgU2VjdGlvbiA0LjIKClRoZSB0ZXJtICJOZWdhdGl2ZSBDYWNoaW5nIiB1c3Vh bGx5IGluZGljYXRlcyBtYWtpbmcgbm90ZSBvZiB0aGUKKmFic2VuY2UqIG9mIHNwZWNpZmljIGlu Zm9ybWF0aW9uIChmb3IgdGhlIGR1cmF0aW9uIG9mIGEgY2VydGFpbgp0aW1lIHNwYW4pLiAgSW4g U2VjdGlvbiA0LjIsIGl0IGlzIG5vdCBjbGVhciB3aGF0IGV4YWN0bHkgaXMKJ25lYWd0aXZlbHkg Y2FjaGVzJyBpbiB0aGlzIGNvbnRleHQuICBJbiBwYXJ0aWN1bGFyLCB0aGUgc2VudGVuY2UgLi4u CgogICBJZiBMZWFzZXF1ZXJpZXMgcmVzdWx0IGluIG5lZ2F0aXZlIGNhY2hlcywgLi4uCgouLi4g aXMgcmF0aGVyIHZhZ3VlIGFuZCBpbXByZWNpc2UuCgpJIHdvdWxkIGxpa2UgdG8gc2VlIGEgYmV0 dGVyIGV4cGxhbmF0aW9uIG9mIHdoYXQgaXMgbWVhbnQgd2l0aAp0aGF0IHRlcm0gaW4gdGhpcyBj b250ZXh0LgoKCig1KSAgU2VjdGlvbiA0LjMgLS0gbWlzc2luZyBhcnRpY2xlCgpJIHN1Z2dlc3Qg dG8gaW5zZXJ0IHRoZSBkZWZpbml0ZSBhcnRpY2xlIGluIGZyb250IG9mICJmYXN0IHBhdGgiOgoK fCAgSWYgQW50aXNwb29maW5nIGlzIG5vdCBkb25lIGluIGZhc3QgcGF0aCwgaXQgd2lsbCBiZWNv bWUgYSBib3R0bGVuZWNrCiAgIGFuZCBtYXkgbGVhZCB0byBkZW5pYWwgb2Ygc2VydmljZSBvZiB0 aGUgYWNjZXNzIGNvbmNlbnRyYXRvci4gIFRoZQogICBMZWFzZXF1ZXJpZXMgc2hvdWxkIG1ha2Ug aXQgcG9zc2libGUgdG8gZG8gYW50aXNwb29maW5nIGluIGZhc3QgcGF0aC4KLS0tICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdnZ2dnYKfCAgSWYgQW50aXNwb29maW5nIGlzIG5vdCBkb25l IGluIHRoZSBmYXN0IHBhdGgsIGl0IHdpbGwgYmVjb21lIGEKICAgYm90dGxlbmVjayBhbmQgbWF5 IGxlYWQgdG8gZGVuaWFsIG9mIHNlcnZpY2Ugb2YgdGhlIGFjY2VzcwogICBjb25jZW50cmF0b3Iu ICBUaGUgTGVhc2VxdWVyaWVzIHNob3VsZCBtYWtlIGl0IHBvc3NpYmxlIHRvIGRvCiAgIGFudGlz cG9vZmluZyBpbiBmYXN0IHBhdGguCgoKKDYpICBTZWN0aW9uIDQuNCwgMm5kIHBhcmFncmFwaCAt LSBtaXNzaW5nIGFydGljbGUKClNpbWlsYXJseSBhcyBhYm92ZSwgSSBzdWdnZXN0IHRvIG1vZGlm eToKCnwgIEJ1bGsgTGVhc2VxdWVyeSBhbGxvd3Mgc3BlY2lmaWNhdGlvbiBvZiBhIHF1ZXJ5LXN0 YXJ0LXRpbWUgYXMgd2VsbCBhcwogICBhIHF1ZXJ5LWVuZC10aW1lLiAgVXNlIG9mIHF1ZXJ5LXRp bWVzIGFsbG93cyBhIG5ldHdvcmsgZWxlbWVudCB0aGF0CiAgIHBlcmlvZGljYWxseSBjb21taXRz IGluZm9ybWF0aW9uIHRvIHN0YWJsZSBzdG9yYWdlIHRvIHJlY292ZXIganVzdAogICB3aGF0IGl0 IGxvc3Qgc2luY2UgdGhlIGxhc3QgY29tbWl0LgotLS0gICAgICAgICAgICAgICAgICAgICAgdnZ2 dnYKfCAgQnVsayBMZWFzZXF1ZXJ5IGFsbG93cyB0aGUgc3BlY2lmaWNhdGlvbiBvZiBhIHF1ZXJ5 LXN0YXJ0LXRpbWUgYXMKICAgd2VsbCBhcyBhIHF1ZXJ5LWVuZC10aW1lLiAgVXNlIG9mIHF1ZXJ5 LXRpbWVzIGFsbG93cyBhIG5ldHdvcmsKICAgZWxlbWVudCB0aGF0IHBlcmlvZGljYWxseSBjb21t aXRzIGluZm9ybWF0aW9uIHRvIHN0YWJsZSBzdG9yYWdlIHRvCiAgIHJlY292ZXIganVzdCB3aGF0 IGl0IGxvc3Qgc2luY2UgdGhlIGxhc3QgY29tbWl0LgoKCig3KSAgU2VjdGlvbiA1IC0tIG1pc3Np bmcgaW1wb3J0YW50IGRldGFpbHMKCkluIHRoZSBwcm90b2NvbCBvdmVydmlldywgSSBtaXNzIG1l bnRpb24gb2YgdGhlICdub3JtYWwnIHJlc3BvbnNlCm1lc3NhZ2VzIC0tIGl0IHRha2VzIHVidGls IHNlY3Rpb24gNy4yIHVudGlsIHRoZSByZWFkZXIgbm90IGZsdWVudAp3aXRoIHRoZSBiYXNpYyBM ZWFzZXF1ZXJ5IHByb3RvY29sIGRldGFpbHMgYmVjb21lcyBhd2FyZSBvZiB0aGUKZmFjdCB0aGF0 IERIQ1BMRUFTRVVOQVNTSUdORUQgYW5kIERIQ1BMRUFTRUFDVElWRSBhcmUgdGhlICdub3JtYWwn CnJlc3BvbnNlIG1lc3NhZ2VzIHVzZWQuCgpQZXJoYXBzLCBhbiBleHBsYW50aW9uIHRvIHRoaXMg ZW5kIHNob3VsZCBiZSBpbnNlcnRlZCBhZnRlciB0aGUKZm91cnRoIHBhcmFncmFwaCwgYmVmb3Jl IHRoZSBwYXJhZ3JhcGggYWJvdXQgREhDUExFQVNFUVVFUllET05FLAppbiBvcmRlciB0byByZWZs ZWN0IHRoZSB1c3VhbCB0ZW1wb3JhbCBvcmRlcmluZyBvZiBtZXNzYWdlcy4KCgooOCkgIFNlY3Rp b24gNSwgNnRoIHBhcmFncmFwaCAtLSBuaXRzCgpJbiB0aGUgcHJlc2VudCA2dGggcGFyYWdyYXBo LCBJIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSBjb21tYQoobm90IG5lZWRlZCBpbiB0d28tcGFydHkg ZW51bWVyYXRpb25zKSBhbmQgaW5zZXJ0IGFub3RoZXIgImJ5IgppbiBmcm9udCBvZiAiQ2xpZW50 IElkZW50aWZpZXIiLCBmb3IgY2xhcml0eToKCnwgIEJ1bGsgTGVhc2VxdWVyeSBzdXBwb3J0cyBx dWVyaWVzIGJ5IE1BQyBhZGRyZXNzLCBhbmQgQ2xpZW50CiAgIElkZW50aWZpZXIgaW4gYSB3YXkg c2ltaWxhciB0byBbUkZDNDM4OF0uICBUaGUgQnVsayBMZWFzZXF1ZXJ5CiAgIHByb3RvY29sIGFs c28gYWRkcyBzZXZlcmFsIG5ldyBxdWVyaWVzLgotLS0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHYgICB2dnZ2CnwgIEJ1bGsgTGVhc2VxdWVyeSBzdXBwb3J0 cyBxdWVyaWVzIGJ5IE1BQyBhZGRyZXNzIGFuZCBieSBDbGllbnQKICAgSWRlbnRpZmllciBpbiBh IHdheSBzaW1pbGFyIHRvIFtSRkM0Mzg4XS4gIFRoZSBCdWxrIExlYXNlcXVlcnkKICAgcHJvdG9j b2wgYWxzbyBhZGRzIHNldmVyYWwgbmV3IHF1ZXJpZXMuCgoKKDkpICBTZWN0aW9uIDYKClRoZXIg b3JlZGVyIG9mIHRoZSBsYXN0IHR3byBwYXJhZ3JhcGhzIGlzIGEgYml0IHN1cnByaXNpbmcuCldv dWxkbid0IGl0IGJlIGJldHRlciB0byBmaXJzdCBkZXNjcmliZSB0aGUgZ2VuZXJhbCBiaXRzIGFu ZAp0aGUgbm9ybWFsIGNhc2UgKHByZXNlbnRseSBpbiB0aGUgNXRoIChsYXN0KSBwYXJhZ3JhcGgp IGFuZApzdWJzZXF1ZW50bHkgdGhlIHBlY3VsaWFyaXRpZXMgKGN1cnJlbnRseSBpbiB0aGUgNHRo IHBhcmFncmFwaD8KClRvIHRoaXMgZW5kLCBJIHN1Z2dlc3QgdG8gc2ltcGx5IHN3YXAgdGhlc2Ug dHdvIHBhcmFncmFwaHMsCmFuZCAgIHMvYWJvdmUvYmVsb3cvICBpbiB0aGUgcHJlc2VudCA2dGgg cGFyYWdyYXBoLgoKCigxMCkgIFNlY3Rpb24gNy4yLjIgLS0gbGFuZ3VhZ2UgaW1wcm92ZW1lbnRz CgpJbiB0aGUgZmlyc3QgZW50cnkgbGluZSBvZiB0aGUgc3RhdHVzIGNvZGUgdGFibGUsCkkgc3Vn Z2VzdCB0byBpbnNlcnQgYXJ0aWNsZXMgZm9yIGNsYXJpdHksIGFzIGZvbGxvd3M6Cgp8ICAgIFN1 Y2Nlc3MgICAgICAgICAwMDAgU3VjY2Vzcy4gIEFsc28gc2lnbmFsZWQgYnkgYWJzZW5jZSBvZgp8 ICAgICAgICAgICAgICAgICAgICAgICAgZGhjcC1tZXNzYWdlIG9wdGlvbi4KLS0tCnwgICAgU3Vj Y2VzcyAgICAgICAgIDAwMCBTdWNjZXNzLiAgQWxzbyBzaWduYWxlZCBieSB0aGUgYWJzZW5jZSBv Zgp8ICAgICAgICAgICAgICAgICAgICAgICAgYSBkaGNwLW1lc3NhZ2Ugb3B0aW9uLgogICAgICAg ICAgICAgICAgICAgICAgICAgXl4gICAgICAgICAgICAgICAgICAgICAgICBeXl5eXgoKCigxMSkg IFNlY3Rpb24gNy4yLjgsIGxhc3QgcGFyYWdyYXBoIC0tIHNwdXJpb3VzIHdvcmQgcmVwbGljYXRp b24KClBsZWFzZSAgICBzL3RoZSB0aGUvdGhlLwoKCigxMikgIFNlY3Rpb24gNy4zLCB0YWJsZSBs YXlvdXQKClRvIGVuaGFuY2UgdGhlIHJlYWRhYmlsaXR5LCBwbGVhc2UgYWxpZ24gdGhlIHRhYmxl IGhlYWRpbmcgd2l0aAp0aGUgdGFibGUgY29sdW1ucyBhbmQgc3BhbiwgZm9yIGluc3RhbmNlOgoK ICAgICBQYXJhbWV0ZXIgICAgICAgICAgICAgRGVmYXVsdCAgRGVzY3JpcHRpb24KICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICBCVUxLX0xRX0NPTk5f VElNRU9VVCAgICAgIDMwIHNlY3MgIExlYXNlcXVlcnkgY29ubmVjdGlvbiB0aW1lb3V0CiAgICAg QlVMS19MUV9RVUVSWV9USU1FT1VUICAgICAzMCBzZWNzICBMZWFzZXF1ZXJ5IHF1ZXJ5IHRpbWVv dXQKICAgICBCVUxLX0xRX01BWF9DT05OUyAgICAgICAgIDEwICAgICAgIE1heCBMZWFzZXF1ZXJ5 IFRDUCBjb25uZWN0aW9ucwogICAgIEJVTEtfTFFfTUFYX0NPTk5fUkVUUlkgICAgNjAgc2VjcyAg TWF4IExlYXNlcXVlcnkgcmV0cnkgdGltZW91dAogICAgIEJVTEtfTFFfREFUQV9USU1FT1VUICAg ICAgMzAgc2VjcyAgTGVhc2VxdWVyeSBkYXRhIHRpbWVvdXQKLS0tCiAgICAgUGFyYW1ldGVyICAg ICAgICAgICAgICAgIERlZmF1bHQgICBEZXNjcmlwdGlvbgogICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgQlVM S19MUV9DT05OX1RJTUVPVVQgICAgIDMwIHNlY3MgICBMZWFzZXF1ZXJ5IGNvbm5lY3Rpb24gdGlt ZW91dAogICAgIEJVTEtfTFFfUVVFUllfVElNRU9VVCAgICAzMCBzZWNzICAgTGVhc2VxdWVyeSBx dWVyeSB0aW1lb3V0CiAgICAgQlVMS19MUV9NQVhfQ09OTlMgICAgICAgIDEwICAgICAgICBNYXgg TGVhc2VxdWVyeSBUQ1AgY29ubmVjdGlvbnMKICAgICBCVUxLX0xRX01BWF9DT05OX1JFVFJZICAg NjAgc2VjcyAgIE1heCBMZWFzZXF1ZXJ5IHJldHJ5IHRpbWVvdXQKICAgICBCVUxLX0xRX0RBVEFf VElNRU9VVCAgICAgMzAgc2VjcyAgIExlYXNlcXVlcnkgZGF0YSB0aW1lb3V0CgpbIEFib3ZlLCB0 aGUgbWlkZGxlIGNvbHVtbiBoYXMgYmVlbiBsZWZ0LXNoaWZ0ZWQgYnkgb25lIGNoYXJhY3Rlcgog IHBvc2l0aW9uIGFzIHdlbGwgaW4gb3JkZXIgdG8gYmV0dGVyIGNlbnRlciBpdCEgXQoKCigxMykg IFNlY3Rpb24gOC4yCgooMTNhKSAgMXN0IHBhcmEKCkZvciBlbmhhbmNlZCByZWFkYWJpbGl0eSwg SSBzdWdnZXN0IHRvIHNodWZmbGUgdGhlIHdvcmRpbmcgYSBiaXQKaW4gdGhlIGZpcnN0IHNlbnRl bmNlIChhbmQgaW5zZXJ0IHRoZSBtaXNzaW5nIGFydGljbGUpOgoKICAgQnVsayBMZWFzZXF1ZXJ5 IGlzIGRlc2lnbmVkIHRvIGNyZWF0ZSBhIGNvbm5lY3Rpb24gd2hpY2ggd2lsbAogICB0cmFuc2Zl ciB0aGUgc3RhdGUgb2Ygc29tZSBzdWJzZXQgKG9yIHBvc3NpYmx5IGFsbCkgb2YgdGhlIElQIGFk ZHJlc3MKfCAgYmluZGluZ3MgdG8gdGhlIHJlcXVlc3RvciBmcm9tICBESENQdjQgc2VydmVyLiAg Wy4uLl0KLS0tICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXiBeXl5eXl5eXl5eXl5eXl5eXl5eCiAg IEJ1bGsgTGVhc2VxdWVyeSBpcyBkZXNpZ25lZCB0byBjcmVhdGUgYSBjb25uZWN0aW9uIHdoaWNo IHdpbGwKICAgdHJhbnNmZXIgdGhlIHN0YXRlIG9mIHNvbWUgc3Vic2V0IChvciBwb3NzaWJseSBh bGwpIG9mIHRoZSBJUCBhZGRyZXNzCnwgIGJpbmRpbmdzIGZyb20gdGhlIERIQ1B2NCBzZXJ2ZXIg dG8gdGhlIHJlcXVlc3Rvci4gIFsuLi5dCiAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5e Xl4gXl5eXl5eXl5eXl5eXl5eXgoKKDEzYikgIDNyZCBwYXJhZ3JhcGggLS0gY2xhcmlmaWNhdGlv bgoKVGhlIGRyYWZ0IHByZXNlbnRseSBzYXlzOgoKICAgQSBESENQQlVMS0xFQVNFUVVFUlkgcmVx dWVzdCBpcyBjb25zdHJ1Y3RlZCBvZiBvbmUgb2YgYSBzZXJpZXMgb2YKICAgcHJpbWFyeSBxdWVy aWVzIGFuZCB0aGUgb3B0aW9uYWwgYWRkaXRpb24gb2Ygb25lIG9yIG1vcmUgcXVhbGlmaWVycwog ICB0byB0aG9zZSBwcmltYXJ5IHF1ZXJpZXMuCgpUaGUgdGVybSAic2VyaWVzIiBpcyBjb25mdXNp bmcgaW4gdGhpcyBjb250ZXh0LgpJdCB3aWxsIGluZXZpdGFibHkgcmFpc2UgdGhlIGV4cGVjdGF0 aW9uIGZvciBoYXZpbmcgKm11bHRpcGxlKgpxdWVyaWVzIGFsbG93ZWQgaW4gYSBzaW5nbGUgREhD UEJVTEtMRUFTRVFVRVJZLiAgUmVhZGluZyBvbiwgb3Zlcgp0aGUgbmV4dCBmZXcgcGFnZXMgaXQg YmVjb21lcyBjbGVhciB0aGF0IHRoYXQgZG9lc24ndCBtYWtlIHNlbnNlLgoKVG8gYXZpb2QgdGhp cyBwb3NzaWJsZSBtaXNjb25jZXB0aW9uLCBJIHN1Z2dlc3QgdG8gc2ltcGxpZnkgdGhlIDNyZApw YXJhZ3JhcGggYW5kIHNsaWdodGx5IGltcHJvdmUgdGhlIHdvcmRpbmcgaW4gdGhlIHN1YnNlcXVl bnQgKDR0aCkKcGFyYWdyYXBoOyB0YWtlbiB0b2dldGhlciB0aGVzZSBjb21wcmlzZSBhbGwgbmVj ZXNzYXJ5IHNwZWNpZmljYXRpb24uCgogICBBIERIQ1BCVUxLTEVBU0VRVUVSWSByZXF1ZXN0IGlz IGNvbnN0cnVjdGVkIG9mIG9uZSBvZiBhIHNlcmllcyBvZgogICBwcmltYXJ5IHF1ZXJpZXMgYW5k IHRoZSBvcHRpb25hbCBhZGRpdGlvbiBvZiBvbmUgb3IgbW9yZSBxdWFsaWZpZXJzCiAgIHRvIHRo b3NlIHByaW1hcnkgcXVlcmllcy4KCiAgIFRoZSBwb3NzaWJsZSBwcmltYXJ5IHF1ZXJpZXMgYXJl IGxpc3RlZCBiZWxvdy4gIEVhY2gKICAgREhDUEJVTEtMRUFTRVFVRVJZIHJlcXVlc3QgTVVTVCBj b25zaXN0IG9mIG9ubHkgb25lIG9mIHRoZXNlIHByaW1hcnkKICAgcXVlcmllcy4KLS0tCnwgIEEg REhDUEJVTEtMRUFTRVFVRVJZIHJlcXVlc3QgaXMgY29uc3RydWN0ZWQgb2Ygb25lIHByaW1hcnkg cXVlcnkgYW5kCnwgIG9wdGlvbmFsbHkgb25lIG9yIG1vcmUgcXVhbGlmaWVycyBmb3IgaXQuCgog ICBUaGUgcG9zc2libGUgcHJpbWFyeSBxdWVyaWVzIGFyZSBsaXN0ZWQgYmVsb3cuICBFYWNoCnwg IERIQ1BCVUxLTEVBU0VRVUVSWSByZXF1ZXN0IE1VU1QgY29udGFpbiBvZiBvbmx5IG9uZSBvZiB0 aGVzZSBwcmltYXJ5CiAgIHF1ZXJpZXMuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXl5eXl5eXgoKKDE0KSAgU2VjdGlvbiA4LjMsIHJlc3BvbnNlIG1lc3NhZ2UgYnVsbGV0cwoK QWNjb3JkaW5nIHRvIHRoZSAqdXN1YWwqIHRlbXBvcmFsIG9yZGVyIG9mIGFwcGVhcmFuY2UsIEkg cHJvcG9zZQp0byBtb3ZlIHRoZSBESENQTEVBU0VRVUVSWURPTkUgYnVsbGV0IGJlaGluZCB0aGUg REhDUExFQVNFQUNUSVZFCmFuZCBESENQTEVBU0VVTkFTU0lHTkVEIGJ1bGxldHMuCgpUaGUgREhD UExFQVNFVU5LTk9XTiBidWxsZXQgZG9lcyBub3QgZml0IHVuZGVyIHRoZSBpbnRyb2R1Y3RvcnkK c2VudGVuY2UsCgogICBUaGUgcmVzcG9uc2UgbWVzc2FnZXMgZ2VuZXJhdGVkIGJ5IGEgREhDUEJV TEtMRUFTRVFVRVJZIHJlcXVlc3QgYXJlOgoKVGhlcmVmb3JlLCBJIHN1Z2dlc3QgdG8gdHVybiB0 aGF0IGJ1bGxldCBpbnRvIG5vcm1hbCwgbm9uLWluZGVudGVkCnRleHQ6CgogICAgICBvIERIQ1BM RUFTRVVOS05PV04KCiAgICAgICAgVGhlIERIQ1BMRUFTRVVOS05PV04gbWVzc2FnZSBNVVNUIE5P VCBhcHBlYXIgaW4gYSByZXNwb25zZSB0byBhCiAgICAgICAgQnVsayBMZWFzZXF1ZXJ5LgotLS0K ICAgVGhlIERIQ1BMRUFTRVVOS05PV04gbWVzc2FnZSBNVVNUIE5PVCBhcHBlYXIgaW4gYSByZXNw b25zZSB0byBhIEJ1bGsKICAgTGVhc2VxdWVyeS4KCgooMTUpICBTZWN0aW9uIDguNCwgM3JkIHBh cmFncmFwaAoKVGhhdCBwYXJhIHNheXMgYXQgaXRzIGVuZDoKCiAgICAgICAgICAgWy4uLl0uICBB cyBzdWNoLCBpdCBpcyBhbiBpZGVhbCB0aW1lIHRvIHNhdmUgYW5kIHVzZSBhcyBpbnB1dAogICB0 byBhIERIQ1BCVUxLTEVBU0VRVUVSWSBpbiB0aGUgcXVlcnktc3RhcnQtdGltZSBvciBxdWVyeS1l bmQtdGltZQogICBvcHRpb25zLCBzaG91bGQgdGhlIHJlcXVlc3RvciBuZWVkIHRvIGV2ZXIgaXNz dWUgYSBESENQQlVMS0xFQVNFUVVFUlkKfCAgbWVzc2FnZSB1c2luZyB0aG9zZSBvcHRpb25zIGFz IHBhcnQgb2YgdGhlIHF1ZXJ5LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBeXl4KClRoYXQgaXMgY29uZnVzaW5nOyB3aGljaCBxdWVyeSBpcyBtZWFudCB0aGVyZT8K SSBzdHJvbmdseSBzdXNwZWN0IHlvdSBtZWFuIGZ1dHVyZSBvbmVzLCBhbmQgdGhlcmVmb3JlIHN1 Z2dlc3QKdG8gc2lsZ2hseSBtb2RpZnkgdGhlIHdvcmRpbmcgdG8gZGF5OgoKICAgICAgICAgICBb Li4uXS4gIEFzIHN1Y2gsIGl0IGlzIGFuIGlkZWFsIHRpbWUgdG8gc2F2ZSBhbmQgdXNlIGFzIGlu cHV0CiAgIHRvIGEgREhDUEJVTEtMRUFTRVFVRVJZIGluIHRoZSBxdWVyeS1zdGFydC10aW1lIG9y IHF1ZXJ5LWVuZC10aW1lCiAgIG9wdGlvbnMsIHNob3VsZCB0aGUgcmVxdWVzdG9yIG5lZWQgdG8g ZXZlciBpc3N1ZSBhIERIQ1BCVUxLTEVBU0VRVUVSWQp8ICBtZXNzYWdlIHVzaW5nIHRob3NlIG9w dGlvbnMgYXMgcGFydCBvZiBhIGxhdGVyIHF1ZXJ5LgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBeXl5eXl5eCgpbIFlvdSBtaWdodCB1c2UgImZ1dHVyZSIgaW4gcGxh Y2Ugb2YgImxhdGVyIiwgaWYgeW91IHByZWZlci4gXQoKCigxNikgIFNlY3Rpb24gOC43LCAybmQg cGFyYWdyYXBoCgpUaGUgdGV4dCBzdWRkZW5seSB0dXJucyBmcm9tIHByZXNlbnQgdGVuc2UgdG8g ZnV0dXJlLgpJIHN1Z2dlc3QgdG8gICBzL3dpbGwgbm90IHN1cHBvcnQvZG9lcyBub3Qgc3VwcG9y dC8gICAoMiBpbnN0YW5jZXMpLgoKCgooMTcpICBTZWN0aW9ucyA4LjcgYW5kIDguOAoKSSBtaXNz IHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBUQ1AgVElNRV9XQUlUIHBlY3VsaWFyaXR5LgpXaXRoIFRD UCwgdGhlIHBlZXIgdGhhdCBhY3RpdmVseSBjbG9zZXMgdGhlIGNvbm5lY3Rpb24gbmVlZHMgdG8K cmV0YWluIHN0YXRlIGZvciBhIHNpZ25pZmljYW50IHRpbWUgc3BhbiwgaW4gb3JkZXIgdG8gYXZv aWQKY29ubmVjdGlvbiBjbGFzaGVzIG9mIGEgZnV0dXJlIGNvbm5lY3Rpb24gdXNpbmcgdGhlIHNh bWUgdHJhbnNwb3J0CmlkZW50aWZpZXIgKHF1aW50dXBsZSBvZiB0cmFuc3BvcnQgcHJvdG9jb2ws IHNvdXJjZSAmIGRlc3QgYWRkcnMgJgpwb3J0cykgYnkgZGVsYXllZCBwYWNrZXRzIHN0aWxsIGxp bmdlcmluZyBhcm91bmQgaW4gdGhlIG5ldHdvcmsuCgpUaGVyZWZvcmUsIGFzIHJlY2VudCBkaXNj dXNzaW9ucyBpbiBUU1ZXRyBhbmQgVENQTSBoYXZlIHNob3duLAppdCBpcyBpbXBvcnRhbnQgdG8g aGF2ZSwgYnkgYXBwbGljYXRpb24gZGVzaWduLCBhbGwgQ0xPU0VzCm9yZGluYXJpbHkgYmUgcGVy Zm9ybWVkIGJ5IHRoZSBUQ1AgY2xpZW50LCB0aHVzIHNhdmluZyB0aGUKc2VydmVyIGZyb20ga2Vl cGluZyBzdGF0ZSBmb3IgcG90ZW50aWFsbHkgbWFueSBwYXN0IGNsaWVudHMuCkFwcGxpY2F0aW9u IGRlc2lnbmVycyBhbmQgaW1wbGVtZW50ZXJzIC0tIGluIHRoaXMgY2FzZSBESENQCnNlcnZlciBh bmQgY2xpZW50IGltcGxlbWVudGVycyAtLSBzaG91bGQgYmUgcmVtaW5kZWQgdGhhdCBhCkRIQ1Ag c2VydmVyIHNob3VsZCBvbmx5IGFjdGl2ZWx5IGNsb3NlIGEgYnVsayBsZWFzZXF1ZXJ5IFRDUApj b25uZWN0aW9uIGlmIGl0IGlzIGFibGUgYW5kIHdpbGxpbmcgdG8gZGVkaWNhdGUgdGhlIHByb3Rv Y29sCihrZXJuZWwpIHJlc291cmNlcyBmb3IgdGhlIGZ1bGxlIFRJTUVfV0FJVCBwZXJpb2QgKH40 IG1pbiwgcGVyClJGQyA3OTMgYW5kIFNURCAzKS4gIFRoZXJlZm9yZSwgYmVzaWRlcyB1bmRlciBz ZXZlcmUga2VybmVsIG1lbW9yeQpwcmVzc3VyZSwgaXQgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNl IGZvciBhIERIQ1Agc2VydmVyIHRvIGFjdGl2ZWx5CmNsb3NlIGEgVENQIGNvbm5lY3Rpb24gdGhh dCByZWFzb25hYmx5IG1pZ2h0IGJlIHVzZWQgZm9yIGFub3RoZXIKYnVsayBsZWFzZXF1ZXJ5IHRy YW5zYWN0aW9uIHdpdGhpbiBhIHRpbWUgc3BhbiBvZiBzaW1pbGFyIG1hZ25pdHVkZS4KVW5kZXIg bm9ybWFsIG9wZXJhdGlvbnMgY29uZGl0aW9ucywgaXQgc2hvdWxkIGFsd2F5cyBiZSB0aGUKREhD UCBidWxrIGxlYXNlcXVlcnkgY2xpZW50IHRoYXQgYWN0aXZlbHkgY29sc2VzIHRoZSBUQ1AgY29u bmVjdGlvbgphbmQgdGhlcmVieSB1bmRlcnRha2VzIGRlZGljYXRpbmcgVElNRV9XQUlUIHN5c3Rl bSByZXNvdXJjZXMuCgoKKDE4KSAgU2VjdGlvbiA5LjIgLS0gdGV4dHVhbCBpbXByb3ZlbWVudHMK CigxOGEpICA2dGggcGFyYWdyYXBoCgpJIHN1Z2dlc3QgdG8gY2hhbmdlLCBieSBzaHVmZmxpbmcg d29yZHM6CgogICBBIEJ1bGsgTGVhc2VxdWVyeSByZXNwb25zZSBNVVNUIGNvbnRhaW4gbm8gbW9y ZSB0aGFuIG9uZSBtZXNzYWdlIGZvcgogICBlYWNoIGNvbmZpZ3VyZWQgSVAgYWRkcmVzcyBpbiB0 aGUgREhDUHY0IHNlcnZlci4gIFsuLi5dCi0tLSAgICAgXl5eXl5eXl5eXiBeXl5eXl5eXl5eCiAg IEEgQnVsayBMZWFzZXF1ZXJ5IHJlc3BvbnNlIE1VU1QgY29udGFpbiBubyBtb3JlIHRoYW4gb25l IG1lc3NhZ2UgZm9yCiAgIGVhY2ggSVAgYWRkcmVzcyBjb25maWd1cmVkIGluIHRoZSBESENQdjQg c2VydmVyLiAgWy4uLl0KICAgICAgICBeXl5eXl5eXl5eIF5eXl5eXl5eXl4KCigxOGIpICA5dGgg cGFyYWdyYXBoCgpQbGVhc2UgaW5zZXJ0IHRoZSBtaXNzaW5nICJiZSIgOgoKICAgICAgICBbLi4u XS4gIE5vdGUgdGhhdCB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBwcmltYXJ5IHF1ZXJpZXMgYmVs b3cKfCAgbXVzdCBjb25zdHJhaW5lZCBieSB0aGUgYWN0aW9ucyBvZiBhbnkgb2YgdGhlIHRocmVl IHF1YWxpZmllcnMKICAgZGVzY3JpYmVkIHN1YnNlcXVlbnRseSBhcyB3ZWxsLgotLS0KICAgICAg ICBbLi4uXS4gIE5vdGUgdGhhdCB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBwcmltYXJ5IHF1ZXJp ZXMgYmVsb3cKfCAgbXVzdCBiZSBjb25zdHJhaW5lZCBieSB0aGUgYWN0aW9ucyBvZiBhbnkgb2Yg dGhlIHRocmVlIHF1YWxpZmllcnMKICAgICAgIF5eXl4KICAgZGVzY3JpYmVkIHN1YnNlcXVlbnRs eSBhcyB3ZWxsLgoKKDE4YykgICdwcmltYXJ5IHF1ZXJ5JyBidWxsZXRzCgpGb2xsb3dpbmcgdGhl IGV4cGxhbmF0aW9ucyBieSB0aGUgUkZDIEVkaXRvciBpbiBpdHMgSUVURiB0dXRvcmlhbHMKdGhl IG1hbnkgaW5zdGFuY2VzIG9mICd3aGljaCcgaW4gdGhlc2UgYnVsbGV0cyBzaG91bGQgYmUgY2hh bmdlZAp0byAidGhhdCI7IHRvIGF2b2lkICdlcGlkZW1pYyBpbnZhc2lvbicgb2YgInRoYXQicywg SSByZWNvbW1lbmQKdG8gYWx3YXlzIGNoYW5nZSAid2hpY2ggbWF0Y2hlcyIgaW50byAibWF0Y2hp bmciLgpGb3IgaW5zdGFuY2UsIGluIHRoZSBmaXJzdCBidWxsZXQ6CgogICAgICBvIFF1ZXJ5IGJ5 IE1BQyBhZGRyZXNzCgp8ICAgICAgIEV2ZXJ5IElQIGFkZHJlc3Mgd2hpY2ggaGFzIGEgY3VycmVu dCBiaW5kaW5nIHRvIGEgREhDUHY0IGNsaWVudAp8ICAgICAgIHdoaWNoIG1hdGNoZXMgdGhlIGNo YWRkciwgaHR5cGUsIGFuZCBobGVuIGluIHRoZQogICAgICAgIERIQ1BCVUxLTEVBU0VRVUVSWSBy ZXF1ZXN0IE1VU1QgYmUgcmV0dXJuZWQgaW4gYSBESENQTEVBU0VBQ1RJVkUKICAgICAgICBtZXNz YWdlLgotLS0KICAgICAgbyBRdWVyeSBieSBNQUMgYWRkcmVzcwoKfCAgICAgICBFdmVyeSBJUCBh ZGRyZXNzIHRoYXQgaGFzIGEgY3VycmVudCBiaW5kaW5nIHRvIGEgREhDUHY0IGNsaWVudAp8ICAg ICAgIG1hdGNoaW5nIHRoZSBjaGFkZHIsIGh0eXBlLCBhbmQgaGxlbiBpbiB0aGUgREhDUEJVTEtM RUFTRVFVRVJZCiAgICAgICAgcmVxdWVzdCBNVVNUIGJlIHJldHVybmVkIGluIGEgREhDUExFQVNF QUNUSVZFIG1lc3NhZ2UuCgpTaW1pbGFybHksIGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHRo ZSA1dGggYnVsbGV0LCBJIHJlY29tbWVuZCB0bwogICAgcy93aGljaCByZXN0cmljdC9yZXN0cmlj dGluZy8gLgoKKDE4ZCkgICAncXVlcnkgb3B0aW9uJyBidWxsZXRzCgpBZ2FpbiwgIEkgcmVjb21t ZW5kIHRvICAgcy93aGljaC90aGF0L2cgIC4KCkluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGUg M3JkIGJ1bGxldCwgSSByZWNvbW1lbmQgYSBzbWFsbApjbGFyaWZpY2F0aW9uLCB5YiBpbnNlcnRp bmcgImEgVlBOIiBhbmQgYSBjb21tYToKCiAgICAgSW4gYWxsIGNhc2VzLCBpZiB0aGUgaW5mb3Jt YXRpb24gcmV0dXJuZWQgaW4gYSBESENQTEVBU0VBQ1RJVkUgb3IKfCAgICBESENQTEVBU0VVTkFT U0lHTkVEIG1lc3NhZ2UgaXMgZm9yIG90aGVyIHRoYW4gdGhlIGRlZmF1bHQgYSB2cG4taWQKICAg ICBvcHRpb24gTVVTVCBhcHBlYXIgaW4gdGhlIHBhY2tldC4KLS0tCiAgICAgSW4gYWxsIGNhc2Vz LCBpZiB0aGUgaW5mb3JtYXRpb24gcmV0dXJuZWQgaW4gYSBESENQTEVBU0VBQ1RJVkUgb3IKfCAg ICBESENQTEVBU0VVTkFTU0lHTkVEIG1lc3NhZ2UgaXMgZm9yIGEgVlBOIG90aGVyIHRoYW4gdGhl IGRlZmF1bHQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl4g ICAgICAgICAgICAgICAgICAgICAgXgogICAgIGEgdnBuLWlkIG9wdGlvbiBNVVNUIGFwcGVhciBp biB0aGUgcGFja2V0LgoKCigxOSkgIFNlY3Rpb24gOS4zIC0tIHRleHR1YWwgaW1wcm92ZW1lbnRz CgooMTlhKSAgc2Vjb25kIHBhcmFncmFwaAoKSSByZWNvbW1lbmQgcmVwbGFjaW5nICAidGhlIGlk ZW50aWNhbCBmb3IiICBieSBlaXRoZXIgICJpZGVudGljYWwgZm9yIgpvciAgInRoZSBzYW1lIGZv ciIgLgoKKDE5YikgIGJ1bGxldCAjMQoKUGxlYXNlIGNvcnJlY3QsIGFuZCBpbnNlcnQgYSBjb21t YSBmb3IgY2xhcmlmaWNhdGlvbjoKCiAgICAgLi4uIHRoZSBtZXNzYWdlIGJlaW5nIHJldHVybmVk IGluIERIQ1BMRUFTRUFDVElWRSB0aGVuIC4uLgotLS0KICAgICAuLi4gdGhlIG1lc3NhZ2UgYmVp bmcgcmV0dXJuZWQgaXMgREhDUExFQVNFQUNUSVZFLCB0aGVuIC4uLgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBeXiAgICAgICAgICAgICAgICBeCigxOWMpICBidWxsZXQgIzQK ClRoZSBkcmFmdCBzYXlzOgoKICAgICAgNC4gSWYgdGhlIGRoY3AtbGVhc2UtdGltZSBvcHRpb24g Y29kZSBhcHBlYXJzIGluIHRoZSBkaGNwLQogICAgICAgICBwYXJhbWV0ZXItcmVxdWVzdC1saXN0 LCB0aGUgREhDUHY0IHNlcnZlciBNVVNUIGluY2x1ZGUgYSBkaGNwLQogICAgICAgICBsZWFzZS10 aW1lIG9wdGlvbiBmb3IgYW55IHN0YXRlIHRoYXQgaGFzIGEgdGltZS1vdXQgdmFsdWUKfCAgICAg ICAgYXNzb2NpYXRlZCB3aXRoIGl0LCBhbmQgbm90IGp1c3QgYXBwZWFyIGluIGEgREhDUExFQVNF QUNUSVZFCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pwog ICAgICAgICBtZXNzYWdlLiAgVGh1cywgWy4uLl0KClRoZSBmaW5hbCBoYWxmLXNlbnRlbmNlIGRv ZXMgbm90IHBhcnNlLCBhbmQgZG9lcyBub3QgbWFrZSBwcm9wZXIKc2Vuc2UgdG8gbWUuICBQbGVh c2UgbG9vayBmb3IgYSBjbGFyaWZpY2F0aW9uLgoKCigyMCkgIFNlY3Rpb24gMTEKCkZvbGxvd2lu ZyB0aGUgc3Bpcml0IG9mIEJDUCAyNiwgUkZDIDUyMjYsIEkgc3Ryb25nbHkgcmVjb21tZW5kIHRo YXQKeW91IGNob3NlIGEgKnVuaXF1ZSogcGxhY2Vob2xkZXIgZm9yIGVhY2ggY29kZSBwb2ludCB0 byBiZSBhc3NpZ25lZApieSBJQU5BLCBlLmcuLCAiVEJBMSIsICJUQkEyIiwgLi4uICh0byBiZSBh c3NpZ25lZCkuCkRvaW5nIHNvIGhlbHBzIGF2b2lkaW5nIHRyb3VibGUgY2F1c2VkIGJ5IGNsZXJp Y2FsIGVycm9ycyB0aGF0Ci0tIGFzIHRoZSBwYXN0IGhhcyBwYWluZnVsbHkgc2hvd24gLS0gb3Ro ZXJ3aXNlIG1pZ2h0IHJlY3VyIGR1cmluZwp0aGUgZmluYWwgZWRpdG9yaWFsIHByb2Nlc3Npbmcg Y2xlYW51cCBhZnRlciBJQU5BIGFzc2lnbm1lbnQuCgpJbiBidWxsZXQgIzExLCBwbGVhc2UgY29y cmVjdCB0aGUgc3BlbGxpbmcgZXJyb3I6CgogICAgcy9BZGR0aW9uYWwvQWRkaXRpb25hbC8KICAg ICAgICAgICAgICAgICAgIF4KCigyMSkgIFNlY3Rpb25zIDEzLioKCkJhc2VkIG9uIHRyb3VibGUg b2JzZXJ2ZWQgaW4gYW5vdGhlciB0aHJlYWQsIEkgcmVjb21tZW5kIHRoYXQgeW91CmluZGVlZCBm b2xsb3cgdGhlIDNyZCBwYXJhZ3JhcGggb2YgdGhlIHBhZ2UtMSBib2lsZXJwbGF0ZSB0ZXh0CmFu ZCBhZGQgYSBsaXRlcmFsICJ3b3JrIGluIHByb2dyZXNzIiAocGVyaGFwcyBpbiBwYXJlbnRoZXNl cykgdG8KdGhlIEktRCBjaXRhdGlvbnMgeW91IHF1b3RlLgpBcyBoYXMgYmVlbiBzYWlkOiAiVGhl IElFVEYgc2hvdWxkIGVhdCBpdHMgb3duIGRvZ2d5LWZvb2QhIgoKCigyMikgIEFwcGVuZGl4IC0t IG1hbnkgdGV4dHVhbCBpbXByb3ZlbWVudHMKCigyMmEpICAxc3QgYnVsbGV0CgotICAgcy93aGVu IGNsaWVudCBzZW5kcy93aGVuIHRoZSBjbGllbnQgc2VuZHMvCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBeXl5eXgoKKDIyYikgIDJuZCBidWxsZXQsIDJuZCBhbmQgM3JkIHBhcmFncmFwaAoK LSAgcy9iZWNhdXNlIGJlY2F1c2UvYmVjYXVzZS8KCi0gIEkgc3VnZ2VzdCB0byBhbGF5cyByZXBs YWNlICAiY29tZSIgIGJ5ICAiYXJyaXZlIiAgKGZvciBwYWNrZXRzKS4KCi0gIHBsZWFzZSBpbnNl cnQgdGhlIG1pc3NpbmcgYXJ0aWNsZSBpbgoKICAgICAgLi4uIHVudGlsIHRoZSBsZWFzZSBxdWVy eSByZXNwb25zZSAuLi4KICAgICAgICAgICAgICAgXl5eXl4KCigyMmMpICAybmQgYnVsbGV0LCA1 dGggcGFyYWdyYXBoCgogICBzL3BhY2tldHMgdGhhdCB1c2VzL3BhY2tldHMgdGhhdCB1c2UvCiAg ICAgICAgICAgICAgICAgICAgIF4KCigyMmQpICAybmQgYnVsbGV0LCA2dGggYW5kIDd0aCBwYXJh Z3JhcGgKClBsZWFzZSBpbnNlcnQgdGhlIG1pc3NpbmcgYXJ0aWNsZXMgdGFnZ2VkIGJlbG93OgoK ICAgSW4gYSBzcG9vZmluZyB0eXBlIG9mIGF0dGFjaywgbmVnYXRpdmUgY2FjaGluZyBpbmZvcm1h dGlvbiBtYXkgZ3Jvdwp8ICBjb25zaWRlcmFibHkgaWYgdGhlIGF0dGFja2VyIHZhcmllcyB0aGUg c291cmNlIElQIGFkZHJlc3MuICBGb3IgZWFjaAogICAgICAgICAgICAgICAgICBeXl5eXiAgICAg ICAgICAgICAgICAgICAgICAgICAgICB2dnZ2dgp8ICBzdWNoIG5ldyBzb3VyY2UgSVAgYWRkcmVz cywgdHJhZmZpYyB3aWxsIGNvbWUgdG8gdGhlIHNsb3cgcGF0aCwgYSBuZXcKfCAgbGVhc2UgcXVl cnkgbmVlZHMgdG8gYmUgaW5pdGlhdGVkLCB0aGUgcmVzcG9uc2Ugd2lsbCBiZSBwcm9jZXNzZWQs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXgogICBhbmQgbmVnYXRp dmUgY2FjaGluZyBuZWVkcyB0byBiZSBkb25lLiAgVGhhdCB3aWxsIG1lYW4gdXNpbmcgbWFueQog ICByZXNvdXJjZXMgZm9yIG5lZ2F0aXZlIGNhY2hpbmcuCgogICBbUkZDNDM4OF0gc3VnZ2VzdHMg dGhhdCBpZiB0aGUgRFNMQU0ga25vd3MgdGhlIG5ldHdvcmsgcG9ydGlvbiBvZiB0aGUKICAgSVAg YWRkcmVzc2VzIHRoYXQgYXJlIGFzc2lnbmVkIHRvIGl0cyBjbGllbnRzLCB0aGVuIHNvbWUgYW1v dW50IG9mCnwgIGFudGlzcG9vZmluZyBjYW4gYmUgZG9uZSBpbiB0aGUgZmFzdCBwYXRoIGFuZCBz b21lIGxlYXNlIHF1ZXJpZXMgbWF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5e CiAgIGJlIGF2b2lkZWQuICBCdXQgYXMgaW5kaWNhdGVkIGJlZm9yZSwgdGhhdCBpbmZvcm1hdGlv biBtYXkgbm90IGFsd2F5cwogICBiZSBhdmFpbGFibGUgdG8gRFNMQU1zLgoKKDIyZSkgIDJuZCBi dWxsZXQsIDh0aCBwYXJhZ3JhcGgKClRoZSBkcmFmdCBzYXlzOgoKfCAgW1JGQzQzODhdIHNheXMg dGhhdCBESENQdjQgc2VydmVyIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSBiZWluZwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eICAgICAgICAgICAgICAgIHZ2CnwgIGZsb29k ZWQgd2l0aCB0b28gbWFueSBMZWFzZXF1ZXJ5IHJlcXVlc3RzIGFuZCBEU0xBTSBhbHNvIHNob3Vs ZCBub3QKICAgc2VuZCB0b28gbWFueSBsZWFzZSBxdWVyeSBtZXNzYWdlcyBhdCBhIHRpbWUuICBU aGlzIHdvdWxkIG1lYW4gdGhhdAogICBsZWdpdGltYXRlIHJlcXVlc3RvcnMgbWF5IGJlIGV4Y2Vz c2l2ZWx5IGRlbGF5ZWQgZ2V0dGluZyB0aGVpcgp8ICBpbmZvcm1hdGlvbiBpbiB0aGUgZmFjZSBv ZiBhbnRpc3Bvb2ZpbmcgYXR0YWNrcy4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5e Xl5eXl5eXl5eCkluIHRoZSBmaXRzdCBzZW50ZW5jZSwgSU1PIHBsdXJhbCBzaG91bGQgYmUgdXNl ZC4KSW4gdGhlIGxhc3Qgc2VudGVuY2UgZGlkIHlvdSByZWFsbHkgbWVhbiAiYW50aXNwb29maW5n IGF0dGFjayIsCm5vdCAic3Bvb2ZpbmcgYXR0YWNrIiA/Pz8KClRoZXJlZm9yZSwgSSByZWNvbW1l bmQgdG8gbW9kaWZ5IHRoYXQgcGFyYWdyYXBoIHRvIHNheToKCnwgIFtSRkM0Mzg4XSBzYXlzIHRo YXQgREhDUHY0IHNlcnZlcnMgc2hvdWxkIGJlIHByb3RlY3RlZCBmcm9tIGJlaW5nCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eICAgICAgICAgICAgICAgdnZ2CnwgIGZsb29k ZWQgd2l0aCB0b28gbWFueSBMZWFzZXF1ZXJ5IHJlcXVlc3RzIGFuZCBEU0xBTXMgYWxzbyBzaG91 bGQgbm90CiAgIHNlbmQgdG9vIG1hbnkgbGVhc2UgcXVlcnkgbWVzc2FnZXMgYXQgYSB0aW1lLiAg VGhpcyB3b3VsZCBtZWFuIHRoYXQKICAgbGVnaXRpbWF0ZSByZXF1ZXN0b3JzIG1heSBiZSBleGNl c3NpdmVseSBkZWxheWVkIGdldHRpbmcgdGhlaXIKfCAgaW5mb3JtYXRpb24gaW4gdGhlIGZhY2Ug b2Ygc3Bvb2ZpbmcgYXR0YWNrcy4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5e Xl4KCigyMmYpICAzcmQgYnVsbGV0LCAxc3QgcGFyYWdyYXBoCgpJIHN1Z2dlc3QgaW5zZXJ0aW5n IGEgY291cGxlIG9mIG1pc3NpbmcgYXJ0aWNsZXMsIGFuZCBhIGNvbW1hCmZvciBjbGFyaXR5OgoK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbLi4u XS4gKE5vdGUgdGhhdAp8ICB0aGUgYXNzb2NpYXRlZC1pcCBvcHRpb24gZG9lcyBub3QgYXBwZWFy IGluIHJlc3BvbnNlcyBmb3IgYSBxdWVyeSBieQogICBeXl5eICAgICAgICAgICAgICB2dnZ2diAg ICAgICAgICAgICAgICAgICAgdnZ2dnZ2ICAgICAgICBeXl4KfCAgSVAgYWRkcmVzcykuICBXaXRo IHRoZSBhc3NvY2lhdGVkLWlwIG9wdGlvbiwgdGhlIERTTEFNIGNhbiBnZXQKICAgaW5mb3JtYXRp b24gbm90IG9ubHkgYWJvdXQgdGhlIElQIGFkZHJlc3MvTUFDIGFkZHJlc3MgdGhhdCB0cmlnZ2Vy ZWQKICAgdGhlIExlYXNlcXVlcnkgYnV0IGFsc28gYWJvdXQgb3RoZXIgSVAgYWRkcmVzc2VzIHRo YXQgYXJlIGFzc29jaWF0ZWQKICAgd2l0aCB0aGUgb3JpZ2luYWwgTUFDIGFkZHJlc3MuICBUaGF0 IHdheSwgd2hlbiB0cmFmZmljIHRoYXQgdXNlcyB0aGUKfCAgb3RoZXIgSVAgYWRkcmVzc2VzIGNv bWVzIGFsb25nLCB0aGUgRFNMQU0gaXMgYWxyZWFkeSBwcmVwYXJlZCB0byBkZWFsCiAgIHdpdGgg dGhlbS4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eCgooMjJnKSAgM3Jk IGJ1bGxldCwgMm5kIHBhcmFncmFwaAoKVGhlIGNvbW1hIGFmdGVyICJBbHRob3VnaCIgc2hvdWxk IGJlIHJlbW92ZWQgLS0gImlzIGJldHRlciIgYmVsb25ncwp0byB0aGF0IGxlYWRpbmcgd29yZCBh bmQgc2hvdWxkIG5vdCBiZSBzZXBhcmF0ZWQgZnJvbSBpdCBieSB0aGF0IGNvbW1hLgoKTmVhciB0 aGUgZW5kIG9mIHRoZSBwYXJhZ3JhcGgsCgogICAuLi4gcGVyaW9kaWMgcXVlcnlpbmcgd2l0aCBE SENQdjQgc2VydmVyLCAuLi4KCnNob3VsZCBiZXR0ZXIgc2F5OgoKICAgLi4uIHBlcmlvZGljIHF1 ZXJ5aW5nIHRoZSBESENQdjQgc2VydmVyLCAuLi4KICAgICAgICAgICAgICAgICAgICAgICAgIF5e XgoKCk91Z2ghIC0tIFRoYXQncyBpdCBmb3IgdGhpcyB0aW1lLgoKQmVzdCByZWdhcmRzLAogIEFs ZnJlZCBIzm5lcy4KCi0tIAoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBUUi1TeXMgQWxmcmVkIEhvZW5lcyAg IHwgIEFsZnJlZCBIb2VuZXMgICBEaXBsLi1NYXRoLiwgRGlwbC4tUGh5cy4gIHwKfCBHZXJsaW5n ZXIgU3RyYXNzZSAxMiAgIHwgIFBob25lOiAoKzQ5KTcxNTYvOTYzNS0wLCBGYXg6IC0xOCAgICAg ICAgIHwKfCBELTcxMjU0ICBEaXR6aW5nZW4gICAgIHwgIEUtTWFpbDogIGFoQFRSLVN5cy5kZSAg ICAgICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCg== From nortuk@allstream.net Fri Dec 12 08:23:56 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7173A684C for ; Fri, 12 Dec 2008 08:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.201 X-Spam-Level: X-Spam-Status: No, score=-7.201 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvCTMjjsViwh for ; Fri, 12 Dec 2008 08:23:56 -0800 (PST) Received: from Wimax-c3-ppy-pt-190-70-164-101.orbitel.net.co (Wimax-c3-ppy-pt-190-70-164-101.orbitel.net.co [190.70.164.101]) by core3.amsl.com (Postfix) with SMTP id 4ECF13A67F7 for ; Fri, 12 Dec 2008 08:23:53 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212162354.4ECF13A67F7@core3.amsl.com> Date: Fri, 12 Dec 2008 08:23:53 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Fri Dec 12 08:35:52 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643C83A69EA; Fri, 12 Dec 2008 08:35:52 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0589A3A6990; Fri, 12 Dec 2008 08:35:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeeaQxt8ubWb; Fri, 12 Dec 2008 08:35:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CB7A53A684C; Fri, 12 Dec 2008 08:35:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,211,1228089600"; d="scan'208";a="117457882" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 12 Dec 2008 16:35:43 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBCGZhND008702; Fri, 12 Dec 2008 11:35:43 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBCGZhb2008603; Fri, 12 Dec 2008 16:35:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 11:35:43 -0500 Received: from [10.86.250.219] ([10.86.250.219]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 11:35:42 -0500 Message-ID: <494292DD.6050100@cisco.com> Date: Fri, 12 Dec 2008 11:35:41 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Jari Arkko References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> In-Reply-To: <49418E1C.2030009@piuha.net> X-OriginalArrivalTime: 12 Dec 2008 16:35:42.0750 (UTC) FILETIME=[ACD873E0:01C95C77] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5266; t=1229099743; x=1229963743; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20Jari=20Arkko=20; bh=7df2kPzJBtasL3v/wuWdpuHyRR3Dpqgp7dTQtInZT3A=; b=AdGXu3Sn9WqSioAwz+Qz4bwIyT2l785gaudPqL/YYdsgs2ufAs/6ioe5fp Ax0KyYcQ9FRKcnBrYal/pS7KqmiMVsMdwmxcHYiySjXGac8ZkcuBrNCN2PGN cpMs7k4SJg; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks for the explanation and clarification - as you know, I wasn't entirely clear about what issue Lars was concerned about when he first raised his "DISCUSS". I will make the suggested change about the configurable timeout values. and yes, we were trying to specify a way to be somewhat more deterministic than TCP. the goal of the protocol is to support infrastructural use within an operator's network. if one device inside the network can't get a response from another device within 30 seconds, for example, that suggests that something fairly dramatic is happening, and waiting around for the stack's TCP timers isn't necessarily worthwhile. perhaps the choice of the word "block" was a poor one - that'd be my fault. I was intending to mean flow of data, liveness, in the connection, not necessarily referring to a specific posix return status. do you think it's that one word that should be ... universally replaced (with "live" or "liveness", for example)? or should I simply add something that explains better what I mean by it? Thanks, Mark Jari Arkko wrote: > Authors, WG, > > I wanted to report on the status of this draft after tonight's IESG > telechat. Everything else is in order, but Lars Eggert has a > transport-related Discuss. Two issues were raised: > > First, he wants to put in some text to recommend against going lower > than the current timeout values, as too frequent reconnection attempts > or giving up too fast can interfere with the TCP's mechanisms and > cause congestion or even make the application work slower than it > would with TCP. > > This should be easy to do. Here's some suggested text: > > OLD: > Implementations MAY make these values configurable. > NEW: > Implementations MAY make these values configurable. > However, configuring too small timeout values may lead > to harmful behavior both to this application as well > as to other traffic in the network. As a result, > timeout values smaller than the default values are > NOT RECOMMENDED. > > The other issue relates to how the draft has specified timeout > behavior for various stages of the protocol. I just had a long chat > with Lars and we think we understand the situation better now > (authors, please ignore previous e-mail on this topic). > > The high-level question we have is whether all this is necessary. For > instance, the protocol includes retry attempts and timeouts for > opening the connection. Or for maximum waiting time for blocking on > the socket when sending the request. > > TCP will do all this for you. I'm not sure it is worthwhile to try > again, if TCP cannot establish a connection. It already tried very > hard. And if the request/response cannot be sent, TCP will eventually > timeout. Specifying your own timeout behavior will involve some pain > (more on this below). Why do we need to do that? Are we expecting that > this application is special in the sense that its timeliness > requirements are more stringent than TCP's? Are there current > implementations, and do they do this? > > After a lengthy discussion with Lars, we think that your current > scheme works. However, there are a few caveats that may or may not be > obvious: > > By default, send(2) only blocks if the *socket buffer* is full, and > this is not the same as TCP itself being stuck. The fact that you > successfully used the system call to send a small number of bytes, for > instance, does not imply that TCP is making progress. In the bulk > leasequery protocol this would very likely happen for requests. The > end result would be that you'd never block on request. If TCP had > trouble getting the request to the server, you'd eventually timeout on > waiting for the response. > > There are different ways to interpret the word "blocked" in the > specification. Are we using it in the EAGAIN sense i.e., with > non-blocking mode set, or simply in the sense of the send/write > blocking? The latter would be incorrect. For instance, if the server > sends a very large response with one call, it may take a while to > transport everything. But TCP is still making progress, so it would > seem to be inappropriate to fail just because you had a lot of data to > send. > > Finally, behavior at the end of a response becomes interesting > depending on whether or not the socket is closed. If you write some > amount of data to the socket buffer, send/write succeeds but you don't > actually know how long it takes to transport the data. You'll get an > error if TCP fails, but that would be much later. You can do a > blocking close call, however. But I do not know if the server even > cares about whether the data went through... maybe it is enough that > the client waits for all the data to arrive, and eventually gives up > if it does not. > > If we decide to keep the timeout processing in the draft, some > clarification regarding the above should probably be added. > > What do you want to do? > > Jari > > _______________________________________________ > 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 dhcwg-bounces@ietf.org Fri Dec 12 13:13:57 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE6328C205; Fri, 12 Dec 2008 13:13:57 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7256628C1E9; Fri, 12 Dec 2008 13:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9kL+1+bn-+T; Fri, 12 Dec 2008 13:13:55 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9F5CB28C1C9; Fri, 12 Dec 2008 13:13:55 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6C52B198753; Fri, 12 Dec 2008 23:13:48 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1284F1986CE; Fri, 12 Dec 2008 23:13:48 +0200 (EET) Message-ID: <4942D3F0.3070702@piuha.net> Date: Fri, 12 Dec 2008 23:13:20 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Mark Stapp References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> <494292DD.6050100@cisco.com> In-Reply-To: <494292DD.6050100@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Mark, > perhaps the choice of the word "block" was a poor one - that'd be my > fault. I was intending to mean flow of data, liveness, in the > connection, not necessarily referring to a specific posix return > status. do you think it's that one word that should be ... universally > replaced (with "live" or "liveness", for example)? or should I simply > add something that explains better what I mean by it? The change is not that simple. The capabilities of APIs matter; you can't necessarily observe these things directly. The words themselves do not matter as much as explaining what you mean and providing sufficient guidance to implement this on commonly available platforms. I think we should actually discuss the overall strategy a bit before make any changes. Can you speak about why you believe a more deterministic model than what TCP has is needed in this case? (And note that its hard to make the system entirely deterministic.) Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 12 14:17:27 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BD83A6B46; Fri, 12 Dec 2008 14:17:27 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA2C3A68FE; Fri, 12 Dec 2008 14:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN4kF10zSAL9; Fri, 12 Dec 2008 14:17:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D01D03A68B3; Fri, 12 Dec 2008 14:17:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,213,1228089600"; d="scan'208";a="30918654" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Dec 2008 22:17:18 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBCMHHlY021400; Fri, 12 Dec 2008 17:17:17 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBCMHHLG015577; Fri, 12 Dec 2008 22:17:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 17:17:17 -0500 Received: from [10.86.248.86] ([10.86.248.86]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 17:17:16 -0500 Message-ID: <4942E2E5.5040704@cisco.com> Date: Fri, 12 Dec 2008 17:17:09 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Jari Arkko References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> <494292DD.6050100@cisco.com> <4942D3F0.3070702@piuha.net> In-Reply-To: <4942D3F0.3070702@piuha.net> X-OriginalArrivalTime: 12 Dec 2008 22:17:16.0673 (UTC) FILETIME=[642CEF10:01C95CA7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2924; t=1229120237; x=1229984237; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20Jari=20Arkko=20; bh=VE1pbLcrTIsAW0kj5jWPWP1UkR3Ur2xl4NiVP/fHUAM=; b=MfeYOd9Sz+MrIc8B3PfPN14/0LLF13C5hm7Bngnj6RkZiqhXUYGOvtd/qv shWYthgWgs/zrlmosK7XW18/LH9NHPzD871w8hQjOpRYw+ZRt7plXGXrOVjP trHl0Cx676; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I guess I thought we'd supplied pretty explicit guidance already. if you've made a request but you're not receiving any data, you apply the timeout specified. if you're a server and you accept a connection, you apply the timeout if you don't receive a request. I'm not sure there's more "overall strategy" than that: we wanted to make it possible to bound situations where limited resources were tied up. that's not "entirely deterministic" - it's just "be able to bound". if you can't get a 200-byte request message up from an edge router to a more-central server within an operator's network in 30 seconds, there's no point asking the server to wait around for its TCP stack's keepalive timer. at least, that's the default. if an operator _wants_ to raise the timeouts to the multi-minute level, that's permitted by the draft, because the timeouts are configurable. is there a "commonly available platform" where what's described in the text can't be implemented? it's not clear to me now what the issue is. I saw Lars's DISCUSS that said that we should be clear that it's the draft's timeout values that implementations should be applying, because they may not get indications from TCP. I agree, but when I looked at the text I saw that the words already said that - as I was reading them. I asked for a more specific suggestion, to help me address the DISCUSS. but this email, Jari, doesn't seem clear at all about what the objection is. we use TCP. we offer a configurable way to make determinations of progress or liveness that are, by default, more timely than (most) TCPs. an operator who wants to use the 2-hour TCP keepalive can, with the text that's in the draft now. Thanks, Mark Jari Arkko wrote: > Mark, > >> perhaps the choice of the word "block" was a poor one - that'd be my >> fault. I was intending to mean flow of data, liveness, in the >> connection, not necessarily referring to a specific posix return >> status. do you think it's that one word that should be ... >> universally replaced (with "live" or "liveness", for example)? or >> should I simply add something that explains better what I mean by it? > The change is not that simple. The capabilities of APIs matter; you > can't necessarily observe these things directly. The words themselves > do not matter as much as explaining what you mean and providing > sufficient guidance to implement this on commonly available platforms. > > I think we should actually discuss the overall strategy a bit before > make any changes. Can you speak about why you believe a more > deterministic model than what TCP has is needed in this case? (And > note that its hard to make the system entirely deterministic.) > > Jari > > _______________________________________________ > 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 dhcwg-bounces@ietf.org Fri Dec 12 14:30:02 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DE93A6B1B; Fri, 12 Dec 2008 14:30:02 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58ACA3A6B1B for ; Fri, 12 Dec 2008 14:30:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+iG5ZUm19DG for ; Fri, 12 Dec 2008 14:30:01 -0800 (PST) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 30C5A3A68B3 for ; Fri, 12 Dec 2008 14:30:01 -0800 (PST) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 12 Dec 2008 22:29:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBCMTpRd023133; Sat, 13 Dec 2008 09:29:52 +1100 Received: from stealth-10-32-254-179.cisco.com (stealth-10-32-254-179.cisco.com [10.32.254.179]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mBCMTp6E009304; Fri, 12 Dec 2008 22:29:51 GMT References: <30DA64DA-82DB-4A7A-9917-A16BDFF1A712@nominum.com> <8E296595B6471A4689555D5D725EBB2109A315D4@xmb-rtp-20a.amer.cisco.com> Message-Id: <3F012691-EA93-485B-A707-34190AD6A651@cisco.com> From: Richard Johnson To: Ted Lemon In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 14:29:50 -0800 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=906; t=1229120992; x=1229984992; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raj@cisco.com; z=From:=20Richard=20Johnson=20 |Subject:=20Re=3A=20[dhcwg]=20draft-volz-dhc-dhcpv4-vendor- message-00.txt |Sender:=20; bh=1WBRVXkcKoKZcMfvkCUthPOSk6OCCN1UpY1fYsd67YU=; b=SEAi8e4SnMQrdHFbjKfJPaAsk0+d5iDiAM/3RtpRm7gt5rZAHDZ2Jyzd77 CeOEvE2JJceIjZoRpInkHIVG2Qe1yuSXR0nLibcyiOFAOzC40RRAB2C41swr 6JYNTMDW2gKee1I5cu8pvVoLhUS1Qvup7aX0Y7c+0mN1aHfHmXh6Q=; Authentication-Results: syd-dkim-1; header.From=raj@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] draft-volz-dhc-dhcpv4-vendor-message-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org But this draft specifies the existance of a DHCP Message Type option. It's just that the message type is set to 254 and then there's an additional Vendor-specific Message type option. /raj On Nov 19, 2008, at 10:13 PM, Ted Lemon wrote: > On Nov 19, 2008, at 11:58 PM, Bernie Volz (volz) wrote: >> The lack of the DHCP Message Type option may trigger a server to >> assume >> that this is a BOOTP packet? I need to double check RFC 2131 what >> really >> distinguishes a DHCP from a BOOTP, but I think it might be >> existence of >> this option? > > Hm, you raise a good point - a server that doesn't know about this > option might in fact send a BOOTREPLY in response to a DHCP packet > with an unknown vendor-specific type. > > _______________________________________________ > 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 dhcwg-bounces@ietf.org Fri Dec 12 14:44:32 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BBB3A692F; Fri, 12 Dec 2008 14:44:32 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471803A6887 for ; Fri, 12 Dec 2008 14:44:31 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye4RJKX77-S9 for ; Fri, 12 Dec 2008 14:44:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3AB823A68B5 for ; Fri, 12 Dec 2008 14:44:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,213,1228089600"; d="scan'208";a="30885533" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Dec 2008 22:44:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBCMiNbQ032441; Fri, 12 Dec 2008 17:44:23 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBCMiNiG011714; Fri, 12 Dec 2008 22:44:23 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 17:44:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 17:44:02 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109E44101@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <3F012691-EA93-485B-A707-34190AD6A651@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-volz-dhc-dhcpv4-vendor-message-00.txt Thread-Index: AclcqTJM5LFzqxV1QA2C/yBPIW8wLwAAbi8g References: <30DA64DA-82DB-4A7A-9917-A16BDFF1A712@nominum.com> <8E296595B6471A4689555D5D725EBB2109A315D4@xmb-rtp-20a.amer.cisco.com> <3F012691-EA93-485B-A707-34190AD6A651@cisco.com> From: "Bernie Volz (volz)" To: "Richard Johnson (raj)" , "Ted Lemon" X-OriginalArrivalTime: 12 Dec 2008 22:44:23.0348 (UTC) FILETIME=[2DBFD740:01C95CAB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1534; t=1229121863; x=1229985863; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-volz-dhc-dhcpv4-vendor- message-00.txt |Sender:=20 |To:=20=22Richard=20Johnson=20(raj)=22=20,=0 A=20=20=20=20=20=20=20=20=22Ted=20Lemon=22=20; bh=yE93gJ/X70TjA+W9brOhaYQZFy2UStpznV5fMz/AD0c=; b=i1DfH4in+opvoSJLlYAS4LjnzLHXLzx+ZkNEj2BcXfzfYnoV2Zy1J2OJUl Lm9JPNG4LJINZ7z+XRm8f8gdXiE+YqdLOpU2J/c4oa6T+dsV7sjSemIKY40Y 75BCV6kk6A; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-volz-dhc-dhcpv4-vendor-message-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org You lost some of the thread here ... Ted was wondering whether we needed the "DHCP Message Type" option with a Vendor-Message number (254) at all. He was thinking we could just use the new vendor-message option and be done with it. But that doesn't work, I think, because the appearance of the DHCP Message Type option is what makes a BOOTP packet a DHCP packet. - Bernie -----Original Message----- From: Richard Johnson (raj) Sent: Friday, December 12, 2008 5:30 PM To: Ted Lemon Cc: Bernie Volz (volz); dhcwg@ietf.org Subject: Re: [dhcwg] draft-volz-dhc-dhcpv4-vendor-message-00.txt But this draft specifies the existance of a DHCP Message Type option. It's just that the message type is set to 254 and then there's an additional Vendor-specific Message type option. /raj On Nov 19, 2008, at 10:13 PM, Ted Lemon wrote: > On Nov 19, 2008, at 11:58 PM, Bernie Volz (volz) wrote: >> The lack of the DHCP Message Type option may trigger a server to >> assume >> that this is a BOOTP packet? I need to double check RFC 2131 what >> really >> distinguishes a DHCP from a BOOTP, but I think it might be >> existence of >> this option? > > Hm, you raise a good point - a server that doesn't know about this > option might in fact send a BOOTREPLY in response to a DHCP packet > with an unknown vendor-specific type. > > _______________________________________________ > 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 dhcwg-bounces@ietf.org Fri Dec 12 14:47:12 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE543A6887; Fri, 12 Dec 2008 14:47:12 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9810B3A6887 for ; Fri, 12 Dec 2008 14:47:10 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9t0lbZFaai4 for ; Fri, 12 Dec 2008 14:47:09 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A38F33A684C for ; Fri, 12 Dec 2008 14:47:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,213,1228089600"; d="scan'208";a="114938902" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2008 22:47:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mBCMl1Ig016549; Fri, 12 Dec 2008 14:47:01 -0800 Received: from stealth-10-32-254-179.cisco.com (stealth-10-32-254-179.cisco.com [10.32.254.179]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBCMl0lF009177; Fri, 12 Dec 2008 22:47:01 GMT References: <30DA64DA-82DB-4A7A-9917-A16BDFF1A712@nominum.com> <8E296595B6471A4689555D5D725EBB2109A315D4@xmb-rtp-20a.amer.cisco.com> <3F012691-EA93-485B-A707-34190AD6A651@cisco.com> <8E296595B6471A4689555D5D725EBB2109E44101@xmb-rtp-20a.amer.cisco.com> Message-Id: <51BD4265-8350-4520-808F-1C3CDB9BFD60@cisco.com> From: Richard Johnson To: Bernie Volz (volz) In-Reply-To: <8E296595B6471A4689555D5D725EBB2109E44101@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 14:47:00 -0800 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1840; t=1229122021; x=1229986021; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raj@cisco.com; z=From:=20Richard=20Johnson=20 |Subject:=20Re=3A=20[dhcwg]=20draft-volz-dhc-dhcpv4-vendor- message-00.txt |Sender:=20; bh=pYZMa1zxD5zMrQestjXS8nSIzSOqG7DNqGIb+PaF2cw=; b=obxKUyaDsUPBLPhO4dXvWgqGEiuWbA49jua8VOvHMo1UYADMjjOZCLYCtv F0jN+6/4Dzv/CuU9S4+6TzhBv5aALuOsRGRi7FGzuSehoWBXHKgv/wYeqVDe UbP+Gw37Pl; Authentication-Results: sj-dkim-3; header.From=raj@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] draft-volz-dhc-dhcpv4-vendor-message-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Yep, Ted just sent me the same basic note. As I mentioned to him, I was having email problems for a little while after the conference and probably lost that part of the thread. Thanks. /raj On Dec 12, 2008, at 2:44 PM, Bernie Volz (volz) wrote: > You lost some of the thread here ... > > Ted was wondering whether we needed the "DHCP Message Type" option > with > a Vendor-Message number (254) at all. He was thinking we could just > use > the new vendor-message option and be done with it. > > But that doesn't work, I think, because the appearance of the DHCP > Message Type option is what makes a BOOTP packet a DHCP packet. > > - Bernie > > -----Original Message----- > From: Richard Johnson (raj) > Sent: Friday, December 12, 2008 5:30 PM > To: Ted Lemon > Cc: Bernie Volz (volz); dhcwg@ietf.org > Subject: Re: [dhcwg] draft-volz-dhc-dhcpv4-vendor-message-00.txt > > But this draft specifies the existance of a DHCP Message Type option. > It's just that the message type is set to 254 and then there's an > additional Vendor-specific Message type option. > > /raj > > > On Nov 19, 2008, at 10:13 PM, Ted Lemon wrote: > >> On Nov 19, 2008, at 11:58 PM, Bernie Volz (volz) wrote: >>> The lack of the DHCP Message Type option may trigger a server to >>> assume >>> that this is a BOOTP packet? I need to double check RFC 2131 what >>> really >>> distinguishes a DHCP from a BOOTP, but I think it might be >>> existence of >>> this option? >> >> Hm, you raise a good point - a server that doesn't know about this >> option might in fact send a BOOTREPLY in response to a DHCP packet >> with an unknown vendor-specific type. >> >> _______________________________________________ >> 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 noora.obaid@adbic.com Sat Dec 13 12:05:48 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58EC03A69E3 for ; Sat, 13 Dec 2008 12:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.948 X-Spam-Level: *** X-Spam-Status: No, score=3.948 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCNclOP1YwQU for ; Sat, 13 Dec 2008 12:05:47 -0800 (PST) Received: from 157.29.broadband5.iol.cz (157.29.broadband5.iol.cz [88.100.29.157]) by core3.amsl.com (Postfix) with SMTP id BD9243A68A9 for ; Sat, 13 Dec 2008 12:05:44 -0800 (PST) To: Subject: Check it now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213200545.BD9243A68A9@core3.amsl.com> Date: Sat, 13 Dec 2008 12:05:44 -0800 (PST)
Check it now!

Beware! The prices won't keep such low forever!


At the start of 1994, Soros had a huge investment shorting thepositions, was being a bit too clever. One of Wall Streets leading
A Business Week reporter had the chance that summer to ask Soroswar, he responded. I am against nationalism of any kind. If it were
Lately, though, George has broken his vow of silence with a vengeance.Shoneys 790,000 0 From lliand@accept.com.br Sat Dec 13 14:24:13 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B933A69CF for ; Sat, 13 Dec 2008 14:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.886 X-Spam-Level: X-Spam-Status: No, score=-20.886 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72DYNGh41seb for ; Sat, 13 Dec 2008 14:24:13 -0800 (PST) Received: from alexandercalder.nl (unknown [41.196.208.54]) by core3.amsl.com (Postfix) with SMTP id 11BB53A6906 for ; Sat, 13 Dec 2008 14:24:08 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213222410.11BB53A6906@core3.amsl.com> Date: Sat, 13 Dec 2008 14:24:08 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dhcwg-bounces@ietf.org Sun Dec 14 07:03:36 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14823A67B4; Sun, 14 Dec 2008 07:03:35 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942E23A67B4; Sun, 14 Dec 2008 07:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgJn7OI8ru8a; Sun, 14 Dec 2008 07:03:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C12D03A6407; Sun, 14 Dec 2008 07:03:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,219,1228089600"; d="scan'208";a="31025877" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2008 15:03:25 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBEF3PJu019696; Sun, 14 Dec 2008 10:03:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBEF3PCR020401; Sun, 14 Dec 2008 15:03:25 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Dec 2008 10:03:25 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 14 Dec 2008 10:03:24 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3B7C0@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <4942E2E5.5040704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: Aclcp3egltj0kGgERhmXMnA2gRPX6QBVHa7w References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><494292DD.6050100@cisco.com> <4942D3F0.3070702@piuha.net> <4942E2E5.5040704@cisco.com> From: "Bernie Volz (volz)" To: "Mark Stapp (mjs)" , "Jari Arkko" X-OriginalArrivalTime: 14 Dec 2008 15:03:25.0643 (UTC) FILETIME=[1D4C79B0:01C95DFD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4184; t=1229267005; x=1230131005; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Mark=20Stapp=20(mjs)=22=20,=20=22J ari=20Arkko=22=20; bh=OGqpXnd8zb9oMSw0zo4keTUjO18tEqcAvWLL9sdyYgg=; b=GnddXqMpl1pDULOLbzuQZX28e5ek90neHoRPBdPfU4/J6sErROPDXC1m2/ J3pbZF12opv2J5ZFslh+4qla56ZZsced/DLV82NtWrtZgnZj+JM/J53mN7aG apKU92RBW1; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I think one point to keep in mind (for the IESG review) is that this is not a general purpose Internet application protocol to be used across the Internet or by lots of users at any given time. This is designed for use in an operators backbone network (between DHCP relay agents and DHCP servers) and if messages (TCP connections) are delayed for large periods of time, the data itself that is being communicated is unlikely to be current or of significant value. Time is generally of the essence and that is why much shorter timeouts are being applied here -- if the relay agent (well, router that is usually co-located with the relay agent) can not recover the prefix delegations rapidly, the operator's customers' TCP connections will fail. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mark Stapp (mjs) Sent: Friday, December 12, 2008 5:17 PM To: Jari Arkko Cc: Dhcwg; IESG; Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review I guess I thought we'd supplied pretty explicit guidance already. if you've made a request but you're not receiving any data, you apply the timeout specified. if you're a server and you accept a connection, you apply the timeout if you don't receive a request. I'm not sure there's more "overall strategy" than that: we wanted to make it possible to bound situations where limited resources were tied up. that's not "entirely deterministic" - it's just "be able to bound". if you can't get a 200-byte request message up from an edge router to a more-central server within an operator's network in 30 seconds, there's no point asking the server to wait around for its TCP stack's keepalive timer. at least, that's the default. if an operator _wants_ to raise the timeouts to the multi-minute level, that's permitted by the draft, because the timeouts are configurable. is there a "commonly available platform" where what's described in the text can't be implemented? it's not clear to me now what the issue is. I saw Lars's DISCUSS that said that we should be clear that it's the draft's timeout values that implementations should be applying, because they may not get indications from TCP. I agree, but when I looked at the text I saw that the words already said that - as I was reading them. I asked for a more specific suggestion, to help me address the DISCUSS. but this email, Jari, doesn't seem clear at all about what the objection is. we use TCP. we offer a configurable way to make determinations of progress or liveness that are, by default, more timely than (most) TCPs. an operator who wants to use the 2-hour TCP keepalive can, with the text that's in the draft now. Thanks, Mark Jari Arkko wrote: > Mark, > >> perhaps the choice of the word "block" was a poor one - that'd be my >> fault. I was intending to mean flow of data, liveness, in the >> connection, not necessarily referring to a specific posix return >> status. do you think it's that one word that should be ... >> universally replaced (with "live" or "liveness", for example)? or >> should I simply add something that explains better what I mean by it? > The change is not that simple. The capabilities of APIs matter; you > can't necessarily observe these things directly. The words themselves > do not matter as much as explaining what you mean and providing > sufficient guidance to implement this on commonly available platforms. > > I think we should actually discuss the overall strategy a bit before > make any changes. Can you speak about why you believe a more > deterministic model than what TCP has is needed in this case? (And > note that its hard to make the system entirely deterministic.) > > Jari > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 06:30:32 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10513A6A7A; Tue, 16 Dec 2008 06:30:32 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CEA3A6A7A for ; Tue, 16 Dec 2008 06:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvjmz8rXWRZW for ; Tue, 16 Dec 2008 06:30:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2CECB3A69F9 for ; Tue, 16 Dec 2008 06:30:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,231,1228089600"; d="scan'208";a="28773424" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2008 14:30:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBGEUMea028067 for ; Tue, 16 Dec 2008 15:30:22 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBGEUMaV008098 for ; Tue, 16 Dec 2008 14:30:22 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:30:21 +0100 Received: from [10.87.58.73] ([10.86.241.149]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:30:19 +0100 Message-Id: <52AB41B5-F8FC-4EA7-BB13-2DAF91618715@cisco.com> From: Ralph Droms To: dhc WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Dec 2008 05:46:50 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 16 Dec 2008 14:30:20.0848 (UTC) FILETIME=[D3184B00:01C95F8A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1689; t=1229437822; x=1230301822; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20*REMINDER*=3A=20dhc=20WG=20last=20call=20on=20d raft-ietf-dhc-vpn-option-09.txt |Sender:=20; bh=RufjyA82iafR2QRPBDsajlnM6u0fnTkFB6b5Yu7OC2o=; b=Xjt6Gkj0HRPll8LA42pSzX8RA7Z+VmaWLrtg1O5CjGsApSCwKenC6w7tLk zdNlycrpeRAsQD21fFq7rqKnVvqnriLmOsfCNqUtoid6NsAwadYVkbBAix+c NlNzNvfhVJ; Authentication-Results: ams-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org REMINDER: This WG last call will end on Dec 19. We have only received one review of the document, and need several more reviews before the document can be advanced to the IESG. This message announces a WG last call on "Virtual Subnet Selection Options for DHCPv4 and DHCPv6" . The last call will conclude at 1700PDT on December 19, 2008. This document is intended for publication as a Draft Standard. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. Note that there was only one response to the previous WG last call for this document, which is at http://trac.tools.ietf.org/wg/dhc/trac/ticket/12. That response will be considered as part of this new WG last call. draft-ietf-dhc-vpn-option-09.txt defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-09.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 06:30:34 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E906128C0E9; Tue, 16 Dec 2008 06:30:34 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A900B3A6A6E for ; Tue, 16 Dec 2008 06:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVmVmXVp8Uvs for ; Tue, 16 Dec 2008 06:30:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 74BF93A69F9 for ; Tue, 16 Dec 2008 06:30:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,231,1228089600"; d="scan'208";a="28773433" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2008 14:30:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBGEUP2c028085 for ; Tue, 16 Dec 2008 15:30:25 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBGEUPMO008122 for ; Tue, 16 Dec 2008 14:30:25 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:30:25 +0100 Received: from [10.87.58.73] ([10.86.241.149]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:30:24 +0100 Message-Id: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> From: Ralph Droms To: dhc WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Dec 2008 05:50:06 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 16 Dec 2008 14:30:25.0161 (UTC) FILETIME=[D5AA6790:01C95F8A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1278; t=1229437825; x=1230301825; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20REMINDER=3A=20dhc=20WG=20last=20call=20on=20dra ft-ietf-dhc-dhcpv6-reconfigure-rebind-06 |Sender:=20; bh=/QTCDTu68Wgj3EBCR103rpWK5Buj67clsVaWr5ekVb4=; b=uflu7YTcHjSydOe9wvOgQ3bFzgPmkvZsTqRKSymXa/CdXXBEbqUaJhVptd Xa4mM02cNe2OwlBmmsGe/5bMeusoYpKE+z46ZacLthodgFClm5YOMVKir8P7 lPZrQP3vcE; Authentication-Results: ams-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org REMINDER: his WG last call will end on Dec 19. We have only received one review of the document, and need several more reviews before the document can be advanced to the IESG. This message announces a WG last call on "Rebind Capability in DHCPv6 Reconfigure Messages" . The last call will conclude at 1700PDT on 12/19/2008. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. There was insufficient response during the previous WG last call for this document to advance it to the IESG. draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which allows DHCPv6 servers to instruct clients to perform a Rebind operation as well as a Renew operation. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 06:30:41 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3702428C114; Tue, 16 Dec 2008 06:30:41 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EC228C0E3 for ; Tue, 16 Dec 2008 06:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjPYZhvNMX93 for ; Tue, 16 Dec 2008 06:30:38 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E67EC3A69F9 for ; Tue, 16 Dec 2008 06:30:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,231,1228089600"; d="scan'208";a="28773442" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2008 14:30:30 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBGEUUBq017272 for ; Tue, 16 Dec 2008 15:30:30 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBGEUUce008147 for ; Tue, 16 Dec 2008 14:30:30 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:30:29 +0100 Received: from [10.87.58.73] ([10.86.241.149]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:30:28 +0100 Message-Id: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> From: Ralph Droms To: dhc WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Dec 2008 05:51:55 -0500 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 16 Dec 2008 14:30:29.0661 (UTC) FILETIME=[D8590CD0:01C95F8A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1471; t=1229437830; x=1230301830; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20REMINDER=3A=20dhc=20WG=20last=20call=20on=20dra ft-ietf-dhc-relay-id-suboption-04.txt |Sender:=20; bh=AaO8pPxk3HcSVnTDpU3giQ/FlExbM+53Ezm4wUcIj0w=; b=I963sXt+I9oUP8zowbc3qBWjM1IQd+ljKMclMQrZz6/Nz7FVTWZkfZ6bea u7WIiKdgBbrD+wffBne9qKOySNIz2dGhWyNbYB4oNAEUPJsM9g3acsOPzxng QtP24Kv8pd; Authentication-Results: ams-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org REMINDER: This WG last call will end on Dec 19. We have only received one review of the document, and need several more reviews before the document can be advanced to the IESG. This message announces a WG last call on "The DHCPv4 Relay Agent Identifier Suboption" . The last call will conclude at 1700PDT on December 19, 2008. This document is intended for publication as a Proposed Standard. The -04 revision of the document includes changes based on the comments received during the previous last call. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-relay-id-suboption-04.txt defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a unique identifier configured or generated at the relay agent. The suboption allows a DHCP relay agent to include the unique identifier in the DHCP messages it sends. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 09:54:14 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902F828C148; Tue, 16 Dec 2008 09:54:14 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED5028C141; Tue, 16 Dec 2008 09:54:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObtiAYyZscKD; Tue, 16 Dec 2008 09:54:12 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 66B4E28C0E9; Tue, 16 Dec 2008 09:54:12 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBGHrHnv030065; Tue, 16 Dec 2008 10:53:17 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBGHrtnN195712; Tue, 16 Dec 2008 10:54:01 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBGHrtnd002602; Tue, 16 Dec 2008 10:53:55 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-158-204.mts.ibm.com [9.76.158.204]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBGHrsFV002569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:53:55 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBGHrqfu020018; Tue, 16 Dec 2008 12:53:53 -0500 Message-Id: <200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com> To: Jari Arkko In-reply-to: <49418E1C.2030009@piuha.net> References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> Comments: In-reply-to Jari Arkko message dated "Fri, 12 Dec 2008 00:03:08 +0200." Date: Tue, 16 Dec 2008 12:53:52 -0500 From: Thomas Narten Cc: Dhcwg , Mark Stapp , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At the risk of stepping in here without sufficient context, it seems to me that the goal of terminating connections earlier than TCP normally does would be fine -- so long as certain constraints are met. I understand that terminating connections earlier than the normal TCP defaults is the motivation for all this, so corrective action can be taken more quickly. That said, it seems to me to be poor protocol design to terminate the TCP connection early, and then immediately try to reopen a new connection to the same destination to try again (and the current document seems to allow that, via "MAY" language). Doing that risks bypassing TCP's congestion control, etc. And, it's not at all apparent to me why doing that has any real benefit. (I.e., why that would work any better than just waiting for the stalled TCP connection to recover on its own.) I.e., if you just terminated the TCP connection because it wasn't responsive, immediately opening it again and trying again isn't likely to work any better. Yet, the document says: A requestor attempts to establish a TCP connection to a DHCPv4 server in order to initiate a Leasequery exchange. The requestor SHOULD be prepared to abandon the connection attempt after BULK_LQ_CONN_TIMEOUT. If the attempt fails, the requestor MAY retry. Retries MUST use an exponential backoff timer, increasing the interval between attempts up to BULK_LQ_MAX_CONN_RETRY. Which certainly suggests that just trying again immediately is OK. That suggestion is not something we should suggest, IMO. So, I'm curious as to what the real intention here is, with respect to having the timers. I.e., what is an implementation supposed to do when the timer goes off. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 12:14:42 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2D628C146; Tue, 16 Dec 2008 12:14:42 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7C73A6852 for ; Tue, 16 Dec 2008 12:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrKMQiwLmk8q for ; Tue, 16 Dec 2008 12:14:40 -0800 (PST) Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id 3A47928C146 for ; Tue, 16 Dec 2008 12:14:39 -0800 (PST) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id F3A6A33C33; Tue, 16 Dec 2008 12:14:30 -0800 (PST) Date: Tue, 16 Dec 2008 12:14:30 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> References: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: dhc WG Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At Tue, 16 Dec 2008 05:50:06 -0500, Ralph Droms wrote: > REMINDER: his WG last call will end on Dec 19. We have only received > one review of the document, and need several more reviews before the > document can be advanced to the IESG. > > This message announces a WG last call on "Rebind Capability in DHCPv6 > Reconfigure Messages" . > The last call will conclude at 1700PDT on 12/19/2008. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. There was insufficient response during > the previous WG last call for this document to advance it to the IESG. I've read this document and support it. --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 12:18:03 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6E628C146; Tue, 16 Dec 2008 12:18:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683653A6856 for ; Tue, 16 Dec 2008 12:18:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRw3Oe2ejPqv for ; Tue, 16 Dec 2008 12:18:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 663783A6852 for ; Tue, 16 Dec 2008 12:18:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,232,1228089600"; d="scan'208";a="31277067" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2008 20:17:53 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBGKHqBw010136 for ; Tue, 16 Dec 2008 15:17:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBGKHqwQ002465 for ; Tue, 16 Dec 2008 20:17:52 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:17:52 -0500 Received: from kkinnear-wxp01.cisco.com ([161.44.65.110]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:17:51 -0500 Message-Id: <4.3.2.7.2.20081216151727.03d6c008@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Dec 2008 15:18:09 -0500 To: Ralph Droms , dhc WG From: Kim Kinnear In-Reply-To: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> Mime-Version: 1.0 X-OriginalArrivalTime: 16 Dec 2008 20:17:52.0004 (UTC) FILETIME=[5F5A3440:01C95FBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1566; t=1229458673; x=1230322673; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20REMINDER=3A=20dhc=20WG=20last =20call=20on=0A=20=20draft-ietf-dhc-dhcpv6-reconfigure-rebin d-06 |Sender:=20 |To:=20Ralph=20Droms=20,=20dhc=20WG=20; bh=orj/rTNRHTB2Db3/MaPvGJV2kjqnwTyu9KrWqV3IB08=; b=Qv5le3S3gbAcPdJrmZaXCwI+qBC30yMzscLV8QYHPT3YEuCiNH4bl/Gu2v ALcK4xKU2V/oRPrcGIqbexlyPyGBcHTyyu4375yCJe5CLE9ToOmeBw4vjrtO zLCCVD2DVN; Authentication-Results: rtp-dkim-2; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have read this document and support moving it forward. Kim At 05:50 AM 12/16/2008, Ralph Droms wrote: >REMINDER: his WG last call will end on Dec 19. We have only received >one review of the document, and need several more reviews before the >document can be advanced to the IESG. > >This message announces a WG last call on "Rebind Capability in DHCPv6 >Reconfigure Messages" . >The last call will conclude at 1700PDT on 12/19/2008. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. Lack of discussion does not >represent positive support. There was insufficient response during >the previous WG last call for this document to advance it to the IESG. > >draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow >the Rebind message type to appear in the Reconfigure Message option of >a Reconfigure message, which allows DHCPv6 servers to instruct clients >to perform a Rebind operation as well as a Renew operation. The >document also clarifies how a DHCPv6 client responds to a received >Reconfigure message. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt > >- John Brzozowski, Ralph Droms > dhc WG chairs > > > > > > >_______________________________________________ >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 dhcwg-bounces@ietf.org Tue Dec 16 12:20:11 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669843A6868; Tue, 16 Dec 2008 12:20:11 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2373828C178; Tue, 16 Dec 2008 12:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTa3ybqqZnjI; Tue, 16 Dec 2008 12:20:08 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9CD3B3A6868; Tue, 16 Dec 2008 12:20:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,232,1228089600"; d="scan'208";a="31277384" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2008 20:20:01 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBGKK1ga005380; Tue, 16 Dec 2008 15:20:01 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBGKK156016718; Tue, 16 Dec 2008 20:20:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:20:00 -0500 Received: from [10.86.248.23] ([10.86.248.23]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 15:20:00 -0500 Message-ID: <49480D6F.8020102@cisco.com> Date: Tue, 16 Dec 2008 15:19:59 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thomas Narten References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> <200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com> In-Reply-To: <200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com> X-OriginalArrivalTime: 16 Dec 2008 20:20:00.0465 (UTC) FILETIME=[ABEBCC10:01C95FBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2253; t=1229458801; x=1230322801; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20Thomas=20Narten=20; bh=eEc5c5lCChA1LG0MRQf2K0rLxxd8rTXqj6NXPVAijqo=; b=rqwgMDC39ZhbbH5mr4r2w8/D3RuVeZL1I2sUbjzGf5YvWs1N/9p9cRirvC vUwPPXE4Dn/oZ2jyvbuYy8Se2eWv4i5skGz4IlslX/kF6qxx5xCCA9yaKQrp 29jAZ5BELD; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Thomas, so adding text that makes it clear that immediate connection retries is not permitted would address this? that is, the intent has always been to allow periodic connection attempts, with a configurable bound. Thanks, Mark Thomas Narten wrote: > At the risk of stepping in here without sufficient context, it seems > to me that the goal of terminating connections earlier than TCP > normally does would be fine -- so long as certain constraints are met. > > I understand that terminating connections earlier than the normal TCP > defaults is the motivation for all this, so corrective action can be > taken more quickly. > > That said, it seems to me to be poor protocol design to terminate the > TCP connection early, and then immediately try to reopen a new > connection to the same destination to try again (and the current > document seems to allow that, via "MAY" language). Doing that risks > bypassing TCP's congestion control, etc. And, it's not at all apparent > to me why doing that has any real benefit. (I.e., why that would work > any better than just waiting for the stalled TCP connection to recover > on its own.) > > I.e., if you just terminated the TCP connection because it wasn't > responsive, immediately opening it again and trying again isn't likely > to work any better. Yet, the document says: > > A requestor attempts to establish a TCP connection to a DHCPv4 server > in order to initiate a Leasequery exchange. The requestor SHOULD be > prepared to abandon the connection attempt after > BULK_LQ_CONN_TIMEOUT. If the attempt fails, the requestor MAY retry. > Retries MUST use an exponential backoff timer, increasing the > interval between attempts up to BULK_LQ_MAX_CONN_RETRY. > > Which certainly suggests that just trying again immediately is > OK. That suggestion is not something we should suggest, IMO. > > So, I'm curious as to what the real intention here is, with respect to > having the timers. I.e., what is an implementation supposed to do when > the timer goes off. > > Thomas > _______________________________________________ > 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 dhcwg-bounces@ietf.org Tue Dec 16 13:02:07 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B2D28C18C; Tue, 16 Dec 2008 13:02:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C57B28C18C for ; Tue, 16 Dec 2008 13:02:06 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE3u7Vpbrg2S for ; Tue, 16 Dec 2008 13:02:05 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id A953128C173 for ; Tue, 16 Dec 2008 13:02:05 -0800 (PST) Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBGL1vHJ022178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 13:01:58 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 73B425732E; Tue, 16 Dec 2008 13:03:09 -0800 (PST) Date: Tue, 16 Dec 2008 13:03:09 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081216210309.GD3257@isc.org> References: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> MIME-Version: 1.0 In-Reply-To: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660695368==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0660695368== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2008 at 05:51:55AM -0500, Ralph Droms wrote: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.= txt I support the draft moving forward, just a minor wording thing; The type code zero is referred to as being reserved and MUST NOT be used, but the IANA considerations section seems to allocate this code to be named '_NULL'. I'd rather see this named _RESERVED, or placed in a 'reserved range', as that seems less confusing; 0 Reserved 1 RELAY_IDENTIFIER...etc I think the draft can move forward with or without any attempt to address this. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklIF40ACgkQcXeLeWu2vmrIIQCfcdcGbr0x0pJY0IYimZoAWwBr RWQAni4lZArFr9ywuQbfbkI1MjWcS+5U =yssb -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- --===============0660695368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0660695368==-- From dhcwg-bounces@ietf.org Tue Dec 16 13:03:51 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C57028C18C; Tue, 16 Dec 2008 13:03:51 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358E528C189 for ; Tue, 16 Dec 2008 13:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zKfTXHiALYJ for ; Tue, 16 Dec 2008 13:03:49 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4005528C18C for ; Tue, 16 Dec 2008 13:03:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,232,1228089600"; d="scan'208,217";a="31282968" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2008 21:03:41 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBGL3fxO006977; Tue, 16 Dec 2008 16:03:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBGL3fUU020053; Tue, 16 Dec 2008 21:03:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 16:03:41 -0500 Received: from [10.86.248.23] ([10.86.248.23]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 16:03:41 -0500 Message-ID: <494817AC.1090807@cisco.com> Date: Tue, 16 Dec 2008 16:03:40 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "David W. Hankins" References: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> <20081216210309.GD3257@isc.org> In-Reply-To: <20081216210309.GD3257@isc.org> X-OriginalArrivalTime: 16 Dec 2008 21:03:41.0225 (UTC) FILETIME=[C6040990:01C95FC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1626; t=1229461421; x=1230325421; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20REMINDER=3A=20dhc=20WG=20last =20call=09on=09draft-ietf-dhc-relay-id-suboption-04.txt |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20; bh=Q73G1RtW71dJnrSZj+vL+3MrXx6bHR893zc4bJnPBVA=; b=ycVz9LzLxkWtvsXrwJrFKx/R0iJ31MYj0p3bBuRdekDtCbZb3QDj0VEEy9 y3ikZY0MFtansifu4MJTgdLXUsNvVVPSBg/5yB+vYLhW/7K6lobF97/JjmS0 71IfTT3YLy; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DHC WG Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397402833==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1397402833== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, David - I'll make that change to clarify the IANA section.

Regards,
Mark

David W. Hankins wrote: 
On Tue, Dec 16, 2008 at 05:51:55AM -0500, Ralph Droms wrote:
  
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt
    

I support the draft moving forward, just a minor wording thing;

The type code zero is referred to as being reserved and MUST NOT be
used, but the IANA considerations section seems to allocate this code
to be named '_NULL'.  I'd rather see this named _RESERVED, or placed
in a 'reserved range', as that seems less confusing;

		0	Reserved
		1	RELAY_IDENTIFIER...etc

I think the draft can move forward with or without any attempt to
address this.

  

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--===============1397402833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1397402833==-- From dhcwg-bounces@ietf.org Tue Dec 16 13:04:03 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C46228C191; Tue, 16 Dec 2008 13:04:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2773128C190 for ; Tue, 16 Dec 2008 13:04:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba9MtQlx-hEW for ; Tue, 16 Dec 2008 13:04:01 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 7580328C189 for ; Tue, 16 Dec 2008 13:04:01 -0800 (PST) Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBGL3sMm022224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 13:03:54 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 99B6F5732E; Tue, 16 Dec 2008 13:05:06 -0800 (PST) Date: Tue, 16 Dec 2008 13:05:06 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081216210506.GE3257@isc.org> References: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> MIME-Version: 1.0 In-Reply-To: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1023118857==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1023118857== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xm/fll+QQv+hsKip" Content-Disposition: inline --Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2008 at 05:50:06AM -0500, Ralph Droms wrote: > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that I support acceptance of the document. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklIGAIACgkQcXeLeWu2vmqCNQCgtGMC1NY1l4r9iHI8NmTN7K1s WoYAnib61RgigAO3ZGcmJZqE7tZgfTJa =E+xe -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip-- --===============1023118857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1023118857==-- From dhcwg-bounces@ietf.org Tue Dec 16 13:41:21 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E17328C199; Tue, 16 Dec 2008 13:41:21 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0554A28C199 for ; Tue, 16 Dec 2008 13:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvkRyTP-JkQC for ; Tue, 16 Dec 2008 13:41:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 46BE728C14E for ; Tue, 16 Dec 2008 13:41:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,232,1228089600"; d="scan'208,217";a="214225716" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 16 Dec 2008 21:41:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBGLfDUm024440 for ; Tue, 16 Dec 2008 16:41:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBGLfGaH017844 for ; Tue, 16 Dec 2008 21:41:16 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 16:41:12 -0500 Received: from [10.86.248.23] ([10.86.248.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 16:41:12 -0500 Message-ID: <49482077.5060105@cisco.com> Date: Tue, 16 Dec 2008 16:41:11 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: dhcwg X-OriginalArrivalTime: 16 Dec 2008 21:41:12.0721 (UTC) FILETIME=[04031010:01C95FC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2160; t=1229463673; x=1230327673; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20[Fwd=3A=20New=20Version=20Notification=20for=20 draft-ietf-dhc-relay-id-suboption-05] |Sender:=20 |To:=20dhcwg=20; bh=MPuNqE79pBYHrXQRnkjnf5Z1j1tFB2L5NAgSu/ikTVU=; b=BvXY74cDpn+TfWu8LfaQsOSXyh6SorM5OpArHy/OIyLDavSgwOCzIeTbto neCtQYPegDKx8xnOd6ep2g6VSWWaWXz0tNhnvWJ/DKsLbjs4fwX8TWcC9ehW sUaZyKFCu9; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [dhcwg] [Fwd: New Version Notification for draft-ietf-dhc-relay-id-suboption-05] X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1704051099==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1704051099== Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I've posted a new version of the relay-id suboption draft today. The only change was to the IANA considerations section, as suggested by David Hankins, to clarify the 'reserved' value.

Thanks,
Mark

-------- Original Message --------
Subject: New Version Notification for draft-ietf-dhc-relay-id-suboption-05
Date: Tue, 16 Dec 2008 13:39:29 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: mjs@cisco.com 


A new version of I-D, draft-ietf-dhc-relay-id-suboption-05.txt has been successfuly submitted by Mark Stapp and posted to the IETF repository.

Filename:	 draft-ietf-dhc-relay-id-suboption
Revision:	 05
Title:		 The DHCPv4 Relay Agent Identifier Suboption
Creation_date:	 2008-12-16
WG ID:		 dhc
Number_of_pages: 8

Abstract:
This memo 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.  The value may be administratively-configured or
may be generated by the relay agent.  The suboption allows a DHCP
relay agent to include the identifier in the DHCP messages it sends.
                                                                                  


The IETF Secretariat.
--===============1704051099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1704051099==-- From dhcwg-bounces@ietf.org Tue Dec 16 13:43:08 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C8928C19D; Tue, 16 Dec 2008 13:43:08 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A4228C199 for ; Tue, 16 Dec 2008 13:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaX4Jsxu7YjT for ; Tue, 16 Dec 2008 13:43:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A805E28C19A for ; Tue, 16 Dec 2008 13:43:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,232,1228089600"; d="scan'208";a="31285819" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2008 21:42:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBGLgwUi031910 for ; Tue, 16 Dec 2008 16:42:59 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBGLgwbS004476 for ; Tue, 16 Dec 2008 21:42:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 16:42:58 -0500 Received: from [10.86.248.23] ([10.86.248.23]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 16:42:58 -0500 Message-ID: <494820E1.3070208@cisco.com> Date: Tue, 16 Dec 2008 16:42:57 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ralph Droms References: <7199B856-9333-430D-B6D4-E54290C54A6D@cisco.com> In-Reply-To: <7199B856-9333-430D-B6D4-E54290C54A6D@cisco.com> X-OriginalArrivalTime: 16 Dec 2008 21:42:58.0554 (UTC) FILETIME=[4317E5A0:01C95FC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1383; t=1229463779; x=1230327779; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=0 9draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 |Sender:=20 |To:=20Ralph=20Droms=20; bh=ZopYzeZ5gSCyjB/Avf2grLlJKoFLSHkrwKJWwyWxWBs=; b=XP+YZrVvPZnusq6IzuT6ej7rEiGFtHzhGPkhqB8V1uxMr/DKsca24jjkZI 7nq7Ssyi0bDe2o2xspE8bu6DvTUO9j1FCRHCSOn5YiyrC8vpcdR7t2P018y3 mJPlxX986R; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg WG Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have read this draft, and I support its acceptance. -- Mark Ralph Droms wrote: > > This message announces a WG last call on "Rebind Capability in DHCPv6 > Reconfigure Messages" . > The last call will conclude at 1700PDT on 12/19/2008. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. There was insufficient response during > the previous WG last call for this document to advance it to the IESG. > > draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow > the Rebind message type to appear in the Reconfigure Message option of > a Reconfigure message, which allows DHCPv6 servers to instruct clients > to perform a Rebind operation as well as a Renew operation. The > document also clarifies how a DHCPv6 client responds to a received > Reconfigure message. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt > > > - John Brzozowski, Ralph Droms > dhc WG chairs > > > > > > > _______________________________________________ > 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 dhcwg-bounces@ietf.org Tue Dec 16 13:45:04 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D4428C1BD; Tue, 16 Dec 2008 13:45:04 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5E9DC28C19E; Tue, 16 Dec 2008 13:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081216214501.5E9DC28C19E@core3.amsl.com> Date: Tue, 16 Dec 2008 13:45:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-relay-id-suboption-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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) : M. Stapp Filename : draft-ietf-dhc-relay-id-suboption-05.txt Pages : 8 Date : 2008-12-16 This memo 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. The value may be administratively-configured or may be generated by 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-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-16133929.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Dec 16 14:02:25 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3003228C1B4; Tue, 16 Dec 2008 14:02:25 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8ACC28C1B4 for ; Tue, 16 Dec 2008 14:02:23 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5Hcpd36-sF4 for ; Tue, 16 Dec 2008 14:02:22 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id CE0FE28C1AB for ; Tue, 16 Dec 2008 14:02:22 -0800 (PST) Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBGM2Fk8023461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 14:02:15 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 63FD15732E; Tue, 16 Dec 2008 14:03:27 -0800 (PST) Date: Tue, 16 Dec 2008 14:03:27 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081216220327.GH3257@isc.org> References: <49482077.5060105@cisco.com> MIME-Version: 1.0 In-Reply-To: <49482077.5060105@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [dhcwg] [Fwd: New Version Notification for draft-ietf-dhc-relay-id-suboption-05] X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0308980688==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0308980688== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KJY2Ze80yH5MUxol" Content-Disposition: inline --KJY2Ze80yH5MUxol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2008 at 04:41:11PM -0500, Mark Stapp wrote: > I've posted a new version of the relay-id suboption draft today. > The only change was to the IANA considerations section, as suggested by > David Hankins, to clarify the 'reserved' value. That's perfect, thank you Mark. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --KJY2Ze80yH5MUxol Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklIJa8ACgkQcXeLeWu2vmrdEwCdEIjI6SGbUy3HHjnQ3k23d6xP 8i4AnRDiC29+XvgA5AS3sXPd7d6O9zLd =1eXu -----END PGP SIGNATURE----- --KJY2Ze80yH5MUxol-- --===============0308980688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0308980688==-- From dhcwg-bounces@ietf.org Tue Dec 16 14:24:34 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF94E28C1B7; Tue, 16 Dec 2008 14:24:34 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B10D28C1B7; Tue, 16 Dec 2008 14:24:34 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PSYu1d5KQUq; Tue, 16 Dec 2008 14:24:33 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 6DBF628C1A5; Tue, 16 Dec 2008 14:24:31 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBGMNYIq001967; Tue, 16 Dec 2008 17:23:34 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBGMONF9182870; Tue, 16 Dec 2008 17:24:23 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBGMNn9E004662; Tue, 16 Dec 2008 17:23:49 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-158-204.mts.ibm.com [9.76.158.204]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBGMNldU004628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 17:23:48 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBGMOK0Q019006; Tue, 16 Dec 2008 17:24:21 -0500 Message-Id: <200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> To: Mark Stapp In-reply-to: <49480D6F.8020102@cisco.com> References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> <200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com> <49480D6F.8020102@cisco.com> Comments: In-reply-to Mark Stapp message dated "Tue, 16 Dec 2008 15:19:59 -0500." Date: Tue, 16 Dec 2008 17:24:20 -0500 From: Thomas Narten Cc: Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > so adding text that makes it clear that immediate connection retries is > not permitted would address this? that is, the intent has always been to > allow periodic connection attempts, with a configurable bound. Actually, I might express this differently. I think that implementations have always been free to terminate connections whenever they want. We don't need text in any spec to say that. Going back to text in the document: > > A requestor attempts to establish a TCP connection to a DHCPv4 server > > in order to initiate a Leasequery exchange. The requestor SHOULD be > > prepared to abandon the connection attempt after > > BULK_LQ_CONN_TIMEOUT. First,, if the timeout is configurable, then I don't understand why this isn't a MUST (but that is a separate issue) > > If the attempt fails, the requestor MAY retry. > > Retries MUST use an exponential backoff timer, increasing the > > interval between attempts up to BULK_LQ_MAX_CONN_RETRY. This text is what seems out of place to me. An implementation is free to do a number of (possibly ill-advised) things. Why does the spec need to explicitely say this? This sounds to me like someone trying to give a particular implementation explicit permission to do something. I would prefer to just see the text deleted. Looking at additional text (and what probably made Lar's nervous...) > 8.3. Processing Bulk Replies > > The requestor attempts to read a DHCPv4 Leasequery message from the > TCP connection. If the stream of replies becomes blocked, the > requestor SHOULD be prepared to terminate the connection after > BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to > do so. This seems iffy to me. There are many reasons why a connection might block. Maybe the network is now down. Maybe the server is over loaded. Why terminate the connection under such circumstances? The above could actually make the application LESS robust than one would normally expect. Well, OK, if you want to terminate go ahead. But, it would now be completely inappropriate (IMO) to retry the query immediately. If you are going to retry, you really should not have terminated the connection in the first place. That is the standard IETF way of doing things (for good reasons) and IMO, if you want to deviate from that model, you need to explan what problem this is trying to improve upon. So the real question above is, what happens after terminating the connection? Do you expect the transaction to fail and that is it? Or do you expect the application to retry? I have to sort of guess what it is that you expect the requestor to do at this point. What is the actual requirement of the USER of this protocol in this area? > 9.2. Replying to a Bulk Leasequery > > If the connection becomes blocked while the server is attempting to > send reply messages, the server SHOULD be prepared to terminate the > TCP connection after BULK_LQ_DATA_TIMEOUT. This seems even more iffy to me. There are many reasons why a connection might block. One reason could be that the server sent so much data, the client can't consume it. Or the client was suspended (put in background) and isn't reading data anymore. Why terminate the connection under such circumstances? Again, the above could actually make the application LESS robust than one would normally expect (e.g., if the requestor and server have different values configured for the timeout). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 14:28:15 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8454D28C1BD; Tue, 16 Dec 2008 14:28:15 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE4628C116; Tue, 16 Dec 2008 14:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGnoI2ZJ72Gw; Tue, 16 Dec 2008 14:28:13 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 340E828C1A5; Tue, 16 Dec 2008 14:28:13 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7D04E198753; Wed, 17 Dec 2008 00:28:04 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B6CB41986F9; Wed, 17 Dec 2008 00:28:01 +0200 (EET) Message-ID: <49482B4D.2040900@piuha.net> Date: Wed, 17 Dec 2008 06:27:25 +0800 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Mark Stapp References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> <200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com> <49480D6F.8020102@cisco.com> In-Reply-To: <49480D6F.8020102@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Thomas Narten , Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Mark, > so adding text that makes it clear that immediate connection retries > is not permitted would address this? that is, the intent has always > been to allow periodic connection attempts, with a configurable bound. That particular problem would be easy to correct with that. (There were a few things were the document should be more specific or give better guidance, e.g., the nature of blocking with the usual APIs that you have.) However, lets think about what you really achieve with the strategy in the case that Thomas brought up. For an initial period of X seconds you will let TCP handle the opening of the session. Then you will close it (causing a RST to be sent), and stay quiet for Y seconds. At Y seconds you will send a SYN as you re-attempt opening the TCP session. If on the other hand, you simply let TCP deal with the whole thing, you would have had exactly the same behaviour up until X seconds. From there onwards you would have had SYNs sent, attempting to set up the connection. A small number of SYNs are sent at this stage because TCP has already slowed down quite a bit by X seconds if there was no response. And then finally at Z seconds you would give up. You could then attempt re-opening the connection or simply signal failure. What did we achieve with our own timer scheme? AFAICT, in bulk leasequery we can keep trying to contact a server, but if it does not answer, we have no useful alternate strategy. There's typically no other DHCP server to ask for the same information, so all we can do is either keep trying or give up... and alerting management that something is wrong can be done independently of what is going on with the connection opening (if after 10 s you do not have a connection, you could raise an alarm). Also, the strategy of killing the TCP connection attempt sooner does not really reduce the number of packets in the network that much, as TCP has already slowed down. But if we kill the connection, there is no way you can recover between X and Y seconds. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 14:36:07 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3853A69C3; Tue, 16 Dec 2008 14:36:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765303A68A9; Tue, 16 Dec 2008 14:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NamTmHP1gr4x; Tue, 16 Dec 2008 14:36:04 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3603F3A682B; Tue, 16 Dec 2008 14:36:04 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 51553198753; Wed, 17 Dec 2008 00:35:56 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B78411986F9; Wed, 17 Dec 2008 00:35:53 +0200 (EET) Message-ID: <49482D25.4080801@piuha.net> Date: Wed, 17 Dec 2008 06:35:17 +0800 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Thomas Narten References: <20081210144904.8F0A03A68AE@core3.amsl.com> <49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net> <200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com> <49480D6F.8020102@cisco.com> <200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> In-Reply-To: <200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dhcwg , Mark Stapp , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thomas, Mark, > So the real question above is, what happens after terminating the > connection? Do you expect the transaction to fail and that is it? Or > do you expect the application to retry? I have to sort of guess what > it is that you expect the requestor to do at this point. What is the > actual requirement of the USER of this protocol in this area? > I think this is the crux of the issue. A device can open one or multiple bulk leasequery connections to DHCP servers. However, if one of these connections fail, under normal conditions it is not clear to me that there is a useful alternate. (Unless you have failover DHCP servers and you go to the other one). The session data that you were expecting to see is only available from the DHCP server that you are attempting to connect to. So if we don't seem to be making progress, what else can we do than to keep trying? We can certainly tell the human user (irrespective of what is done with the connection) that this is taking a long time. But giving up too early... why? And rerunning the entire query from start, immediately upon failure seems like the wrong thing from congestion etc. perspective. Finally, give up + stay quiet for a while + rerun the query a bit later seems to be less robust than simply letting TCP attempt to make progress. You can't recover during the "stay quiet" period. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 15:44:08 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B881C3A68A9; Tue, 16 Dec 2008 15:44:08 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB6E3A68A9 for ; Tue, 16 Dec 2008 15:44:08 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylGokgpOgr+e for ; Tue, 16 Dec 2008 15:44:07 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 6E80A3A687C for ; Tue, 16 Dec 2008 15:44:07 -0800 (PST) Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBGNi0f3026483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 15:44:00 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 643625732E; Tue, 16 Dec 2008 15:45:12 -0800 (PST) Date: Tue, 16 Dec 2008 15:45:12 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081216234512.GK3257@isc.org> MIME-Version: 1.0 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [dhcwg] dhcpinform-clarify X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0272363572==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0272363572== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WHz+neNWvhIGAO8A" Content-Disposition: inline --WHz+neNWvhIGAO8A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'll have a revision out within the next couple weeks I hope (and as an aside, do that once-over of the option-guidelines draft), but while it is still fresh in my mind, I think someone other than Ted spoke at the mic. at the DHC WG meeting (I think it sounded like Kim?), and all I heard over the mic was he "would have made different choices." If you could just send me a note off-list to identify yourself if you don't have the time, or tell me on-list those choices if you do have time, I'd appreciate it. That goes for anyone else I'm missing. In the next rev I'm working on, I'm not really going to change any existing text yet...want to wait to hear some other opinions first. I aim to finish the bits I left 'under construction'. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --WHz+neNWvhIGAO8A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklIPYgACgkQcXeLeWu2vmqTXQCfeMe6yPuG+u3XbY3XFj7EZdBk LqoAnjlluY23WcWGYZ0b6KD9A1ZftvCM =kGf6 -----END PGP SIGNATURE----- --WHz+neNWvhIGAO8A-- --===============0272363572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0272363572==-- From dhcwg-bounces@ietf.org Tue Dec 16 19:59:43 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729A63A6843; Tue, 16 Dec 2008 19:59:43 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06D33A6843 for ; Tue, 16 Dec 2008 19:59:42 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV6y5Wjvnoji for ; Tue, 16 Dec 2008 19:59:41 -0800 (PST) Received: from kecgate02.infosys.com (kecgate02.infosysconsulting.com [61.95.162.76]) by core3.amsl.com (Postfix) with ESMTP id 020723A680E for ; Tue, 16 Dec 2008 19:59:40 -0800 (PST) X-TM-IMSS-Message-ID: <0a5dc66400025df9@kecgate02.infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by kecgate02.infosys.com ([61.95.162.76]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 0a5dc66400025df9 ; Wed, 17 Dec 2008 09:29:27 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub01.ad.infosys.com ([10.66.236.41]) with mapi; Wed, 17 Dec 2008 09:29:29 +0530 From: Bharat Joshi To: dhc WG Date: Wed, 17 Dec 2008 09:29:04 +0530 Thread-Topic: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt Thread-Index: AclfivDrUzkBE9JYQACvT9OSe1CmggAcNwuO Message-ID: <31D55C4D55BEED48A4459EB64567589A0CD1F55942@BLRKECMBX02.ad.infosys.com> References: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> In-Reply-To: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have read this document and support to move it to next level. Thanks, Bharat ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms [rdroms@cisco.com] Sent: Tuesday, December 16, 2008 4:21 PM To: dhc WG Subject: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt REMINDER: This WG last call will end on Dec 19. We have only received one review of the document, and need several more reviews before the document can be advanced to the IESG. This message announces a WG last call on "The DHCPv4 Relay Agent Identifier Suboption" . The last call will conclude at 1700PDT on December 19, 2008. This document is intended for publication as a Proposed Standard. The -04 revision of the document includes changes based on the comments received during the previous last call. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-relay-id-suboption-04.txt defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a unique identifier configured or generated at the relay agent. The suboption allows a DHCP relay agent to include the unique identifier in the DHCP messages it sends. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ 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 From dhcwg-bounces@ietf.org Tue Dec 16 20:38:18 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205B93A6A7A; Tue, 16 Dec 2008 20:38:18 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8673A6A7A; Tue, 16 Dec 2008 20:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3swtq1PVZEYL; Tue, 16 Dec 2008 20:38:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DE1133A6900; Tue, 16 Dec 2008 20:38:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,234,1228089600"; d="scan'208";a="31282346" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Dec 2008 04:38:07 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBH4c7QG028094; Tue, 16 Dec 2008 23:38:07 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBH4c7Gn019516; Wed, 17 Dec 2008 04:38:07 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 23:38:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Dec 2008 23:30:01 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <49482D25.4080801@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclfzrBkQCxe6fFPSPuiWdGWg1pdtAAMIjIQ References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> From: "Bernie Volz (volz)" To: "Jari Arkko" , "Thomas Narten" X-OriginalArrivalTime: 17 Dec 2008 04:38:07.0155 (UTC) FILETIME=[41C6C830:01C96001] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2696; t=1229488687; x=1230352687; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Jari=20Arkko=22=20,=20=22Th omas=20Narten=22=20; bh=BCYyO7Jm2hpFtN88Alq+pz2oxtMB/kZUd7op4YAj5hA=; b=TF4n6jJqwEQypcyKSQGVg9Pv/U1HdBht0EdKjxb7UM8oRV6+MeDebOJgAq B6XQz/GsVDkJmata/0u5pAUFfDRKf+oaIuYrv3XLd6lc4rGQjy4BuRbZ+oDt UIj0zCdYgH; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org What human user? This protocol is meant to be used by relay agents. There's usually no human involved!! Most DHCP servers and relay agents will NOT want to use normal TCP connection time out times as those might allow connections to be open for hours. As I previously stated, if the data isn't available fairly quickly, it is likely to be stale and not usable. We could argue for years whether 30 second, 120 seconds, 10 minutes or whatever are the right values. If the information isn't available, the relay agent will attempt to recover what it can and go one -- possibly doing individual UDP leasequery as needed to recover leases. Perhaps the solution is just to remove the text regarding connection handling and let implementers do what they want (the text can point out the issues). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Tuesday, December 16, 2008 5:35 PM To: Thomas Narten Cc: Dhcwg; Mark Stapp (mjs); Lars Eggert; IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thomas, Mark, > So the real question above is, what happens after terminating the > connection? Do you expect the transaction to fail and that is it? Or > do you expect the application to retry? I have to sort of guess what > it is that you expect the requestor to do at this point. What is the > actual requirement of the USER of this protocol in this area? > I think this is the crux of the issue. A device can open one or multiple bulk leasequery connections to DHCP servers. However, if one of these connections fail, under normal conditions it is not clear to me that there is a useful alternate. (Unless you have failover DHCP servers and you go to the other one). The session data that you were expecting to see is only available from the DHCP server that you are attempting to connect to. So if we don't seem to be making progress, what else can we do than to keep trying? We can certainly tell the human user (irrespective of what is done with the connection) that this is taking a long time. But giving up too early... why? And rerunning the entire query from start, immediately upon failure seems like the wrong thing from congestion etc. perspective. Finally, give up + stay quiet for a while + rerun the query a bit later seems to be less robust than simply letting TCP attempt to make progress. You can't recover during the "stay quiet" period. Jari _______________________________________________ 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 dhcwg-bounces@ietf.org Tue Dec 16 21:40:23 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B063A691E; Tue, 16 Dec 2008 21:40:23 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6911F3A67D7; Tue, 16 Dec 2008 21:40:21 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVPfPkOCYR6l; Tue, 16 Dec 2008 21:40:20 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 05C553A691E; Tue, 16 Dec 2008 21:40:09 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSUiQsbxQkMlz733vCEVuHUqqIxWUippJ@postini.com; Tue, 16 Dec 2008 21:40:13 PST 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 shell-too.nominum.com (Postfix) with ESMTP id 719DF1B8278; Tue, 16 Dec 2008 21:03:54 -0800 (PST) Received: from [64.89.227.148] (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 21:03:43 -0800 Message-ID: From: Ted Lemon To: Bernie Volz In-Reply-To: <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 23:03:39 -0600 References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: Thomas Narten , "Mark Stapp \(mjs\)" , IESG , Lars Eggert , Dhcwg Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Why would a broken TCP connection stay up for 10 minutes? Shouldn't it die within 90 seconds if no ACKs are forthcoming from the remote end? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 21:51:45 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C75C3A6AC8; Tue, 16 Dec 2008 21:51:45 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262973A6ACF for ; Tue, 16 Dec 2008 21:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP-SfqKT2ohC for ; Tue, 16 Dec 2008 21:51:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 584C03A6AC8 for ; Tue, 16 Dec 2008 21:51:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,235,1228089600"; d="scan'208";a="31286842" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Dec 2008 05:51:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBH5pYCZ016114 for ; Wed, 17 Dec 2008 00:51:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBH5pYpA003743 for ; Wed, 17 Dec 2008 05:51:34 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 00:51:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 00:48:03 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C263@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <52AB41B5-F8FC-4EA7-BB13-2DAF91618715@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt Thread-Index: AclfitkmXKUHCaH/T5+dVCz/2wfKYAAfohCA References: <52AB41B5-F8FC-4EA7-BB13-2DAF91618715@cisco.com> From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , "dhc WG" X-OriginalArrivalTime: 17 Dec 2008 05:51:34.0540 (UTC) FILETIME=[84C85CC0:01C9600B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1382; t=1229493094; x=1230357094; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20*REMINDER*=3A=20dhc=20WG=20la st=20call=20on=20draft-ietf-dhc-vpn-option-09.txt |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =20=22dhc=20WG=22=20; bh=1S6AnLY1PKbkh4WfPdLZTMLH7r+6xi9cwJeRhaMtgWU=; b=wbQTsn2hWG91EkPeoBHgHJG+GaIey857lWW8sRjc+LAYpVPhpQQOJkjtDk Trt4BxWHbgO7ErSkYPqH9/ObzG5bM4br8Wib3tmEnmc7mPA046NznkDcdXop 8KBW0jUZLC; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I fully support this document moving forward. There are two minor issues that we might want to consider: 1. Should there be any text suggesting what the server should send back? Perhaps we should recommend that if the server sends back the VPN (sub)option, it SHOULD return the VPN information in the same format it was provided by the client/relay (ie, name vs VRF) if possible. And, if it must send the option when the client/relay did not provide it, it should prefer to send back the VRF (if available)? Perhaps in 7. Server Behavior, we could add: If a server uses a different VPN than what it received, it SHOULD send back the VPN information using the same type as the received type. It MAY send back a different type if it is not possible to use the same type (such as the RFC2685 VPN-ID if no ASCII VPN identifier exists). 2. For v6 (could also be an issue for v4), what happens if the client/relay provides this option in the ORO (PRL)? And, should the client/relay, if it wants it sent back, include it in the ORO (PRL)? Perhaps we consider this a "core" protocol option (similar to the IA_NA, IA_PD, IA_TA) where the option is not required to be in the ORO (PRL) as the semantics require the server to send it back if received. Again, both of these are minor and I think the document is fine "as is". - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 21:51:46 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5056528C110; Tue, 16 Dec 2008 21:51:46 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370223A6AC8; Tue, 16 Dec 2008 21:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onJVGPzaXqOG; Tue, 16 Dec 2008 21:51:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3E5113A6ABC; Tue, 16 Dec 2008 21:51:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,235,1228089600"; d="scan'208";a="31322817" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Dec 2008 05:51:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBH5pYAg010638; Wed, 17 Dec 2008 00:51:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBH5pYQN003740; Wed, 17 Dec 2008 05:51:34 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 00:51:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 00:46:53 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclgCfElEjS7jadJRyKRDcP0jT0iTAAABNJA References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "Ted Lemon" X-OriginalArrivalTime: 17 Dec 2008 05:51:34.0478 (UTC) FILETIME=[84BEE6E0:01C9600B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1209; t=1229493094; x=1230357094; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Ted=20Lemon=22=20; bh=+myUzKD/Z3lZDddJGacQdMe9hKZvmeKzib3PPGMgDlc=; b=jE9LiKM9P22h5X3V0CNuk/OCRY0PBny7gUkwYq4FxifF5P+F1NwqAjLUDV /wVv52w9BltOC7YSctBgO23SQW54yqCt6/YesdVP6vl352muPB8q7ZiVMXU3 0KpQZV1Puc; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Thomas Narten , "Mark Stapp \(mjs\)" , IESG , Lars Eggert , Dhcwg Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Oh, no way! If the both ends enable keep-alives (some stacks do by default), the there will be periodic probes but they generally don't time out for minutes (I think for most BSD systems it works out to 9 or more if I remember correctly). And, if no keep-alives are sent, if the server crashes, the relay may be waiting forever. While everyone mentions non-fatal failures -- such as slow servers -- there are lots of other conditions that could cause a significant delay in detecting a downed server or relay agent. These connections are mostly a one-way data flow - relay agent sends a request, server sends lots of responses. TCP is great, don't get me wrong, but sometimes you need faster response than it offers. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, December 17, 2008 12:04 AM To: Bernie Volz (volz) Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Why would a broken TCP connection stay up for 10 minutes? Shouldn't it die within 90 seconds if no ACKs are forthcoming from the remote end? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 16 23:51:17 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B613A68AC; Tue, 16 Dec 2008 23:51:17 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56923A689E for ; Tue, 16 Dec 2008 23:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JifSz3MDIEN for ; Tue, 16 Dec 2008 23:51:15 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 92A333A687C for ; Tue, 16 Dec 2008 23:51:14 -0800 (PST) Received: by bwz14 with SMTP id 14so5113206bwz.13 for ; Tue, 16 Dec 2008 23:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=7C18umj5f4cSekxmfHl8Gm7Ia7SPC7CHg9q9DjXbugM=; b=OAOro6sfvaMdcwWobjn9MckVNxItwos1GyR9a8lSEWndfCF/TVk6B0IIzBJqiY46nS k0O/oeWrGpwK6gauea9CfC6gNFsOKaTi8WSRIGElLtL07n3kd59aMNOhsTP7oXZMhHxh BtlFGjaQTZNmPWG1yTRlt8iJoYnMLrpgeOfaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=hmUbENcfceYMEjYgO6Krzlh2ENry2XJ4krlxML2XIB/yT51b/VEjDvHnpBIrTcXYJQ dF+scd2OWg+IPuWoz6Sn+KqfF4h0jySSlopKoflbIbtHoGK6i2LIOJg63/xCyRWc1smm /Txaa/fpwTMaDPDZj5raywrblvgTdXXfewyOY= Received: by 10.181.229.12 with SMTP id g12mr145770bkr.176.1229500265961; Tue, 16 Dec 2008 23:51:05 -0800 (PST) Received: by 10.180.208.11 with HTTP; Tue, 16 Dec 2008 23:51:05 -0800 (PST) Message-ID: <521a93e30812162351h5afdc5e0h9d062ea1d0dcfb5b@mail.gmail.com> Date: Wed, 17 Dec 2008 09:51:05 +0200 From: "=?ISO-8859-1?Q?Nils_K=F6rber?=" To: "dhc WG" In-Reply-To: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> MIME-Version: 1.0 References: <6A6C46C4-EAE4-4938-93A2-90301B3F4964@cisco.com> X-Google-Sender-Auth: cb7b7736a2bb1579 Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0052272286==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0052272286== Content-Type: multipart/alternative; boundary="----=_Part_3760_8619318.1229500265955" ------=_Part_3760_8619318.1229500265955 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I support moving the document forward. Cheers from South Africa, Nils On Tue, Dec 16, 2008 at 12:50 PM, Ralph Droms wrote: > REMINDER: his WG last call will end on Dec 19. We have only received one > review of the document, and need several more reviews before the document > can be advanced to the IESG. > > This message announces a WG last call on "Rebind Capability in DHCPv6 > Reconfigure Messages" . > The last call will conclude at 1700PDT on 12/19/2008. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. There was insufficient response during > the previous WG last call for this document to advance it to the IESG. > > draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow > the Rebind message type to appear in the Reconfigure Message option of > a Reconfigure message, which allows DHCPv6 servers to instruct clients > to perform a Rebind operation as well as a Renew operation. The > document also clarifies how a DHCPv6 client responds to a received > Reconfigure message. This draft is available as > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt > > - John Brzozowski, Ralph Droms > dhc WG chairs > > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > ------=_Part_3760_8619318.1229500265955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I support moving the document forward.

Cheers from South Africa,

Nils


On Tue, Dec 16, 2008 at 12:50 PM, Ralph Droms <rdroms@cisco.com> wrote:
REMINDER: his WG last call will end on Dec 19.  We have only received one review of the document, and need several more reviews before the document can be advanced to the IESG.

This message announces a WG last call on "Rebind Capability in DHCPv6
Reconfigure Messages" <draft-ietf-dhc-dhcpv6-reconfigure-rebind-06>.
The last call will conclude at 1700PDT on 12/19/2008.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  There was insufficient response during
the previous WG last call for this document to advance it to the IESG.

draft-ietf-dhc-dhcpv6-reconfigure-rebind-06 updates RFC 3315 to allow
the Rebind message type to appear in the Reconfigure Message option of
a Reconfigure message, which allows DHCPv6 servers to instruct clients
to perform a Rebind operation as well as a Renew operation.  The
document also clarifies how a DHCPv6 client responds to a received
Reconfigure message.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt

- John Brzozowski, Ralph Droms
 dhc WG chairs






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

------=_Part_3760_8619318.1229500265955-- --===============0052272286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0052272286==-- From dhcwg-bounces@ietf.org Wed Dec 17 05:27:22 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B0328C1BD; Wed, 17 Dec 2008 05:27:21 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD453A6904; Wed, 17 Dec 2008 05:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.596 X-Spam-Level: X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=-1.985, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrwJbLUkkw1v; Wed, 17 Dec 2008 05:27:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B1BE63A67E6; Wed, 17 Dec 2008 05:27:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,237,1228089600"; d="scan'208";a="31311465" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Dec 2008 13:26:46 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBHDQkqU015348; Wed, 17 Dec 2008 08:26:46 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHDQkOb001074; Wed, 17 Dec 2008 13:26:46 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 08:26:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 08:26:24 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C296@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclgG1LuHy2+etZSRg6SvGJ7HIbN4QAL1knw References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> From: "Bernie Volz (volz)" To: "Lars Eggert" X-OriginalArrivalTime: 17 Dec 2008 13:26:46.0338 (UTC) FILETIME=[1BE20220:01C9604B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2929; t=1229520406; x=1230384406; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Lars=20Eggert=22=20; bh=QBy47KkPfRj190Vt2x79mb+B7Q6mMjHiNYxQ9kpGZfc=; b=C5o7o2GhFm9b8/5bCMWDXXc8kp733YH2qHSEKgEUxPr/aB6fQHyPJKPH4v /ywVHrP2YUJZA8ji98HqdP58chtI9nR+0GVc7uuPWFF8bbhhKG8ShuqFtxDQ G77vacFXSS; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Thomas Narten , "Mark Stapp \(mjs\)" , IESG , Dhcwg , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org There are two cases: 1. Responses (from the server to relay) are blocked because relay isn't reading data fast enough. 2. Responses (from the server to relay) have stopped being sent because the server is not there. In case 1, the relay would never know about connection issues since it isn't reading. This can also mean that there is a communication problem. Or, it could mean (at least for a short time) that the relay is gone -- if the window was full when the relay went down, it will take a periodic probe to discover that. In case 2, the relay would be waiting for data that never arrives. We're worried more about case 2. - Bernie -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wednesday, December 17, 2008 2:44 AM To: Bernie Volz (volz) Cc: Ted Lemon; Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: > Oh, no way! > > If the both ends enable keep-alives (some stacks do by default), the > there will be periodic probes but they generally don't time out for > minutes (I think for most BSD systems it works out to 9 or more if I > remember correctly). TCP keep-alives only kick in when there is no data to send in both directions, which isn't the case you're worried about. In your case, one end is trying to send data, but the throughput it is achieving isn't considered sufficient. The timeouts for failing to make send progress are usually on the order of minutes in typical stacks and often configurable via setsockopt. (For some more background information, see draft-ietf-tcpm-tcp-uto.) > And, if no keep-alives are sent, if the server crashes, the relay > may be > waiting forever. Not if it is trying to send data and not making progress. Lars PS: And yes, Thomas note pretty much matches my concerns with the document. > While everyone mentions non-fatal failures -- such as slow servers -- > there are lots of other conditions that could cause a significant > delay > in detecting a downed server or relay agent. > > These connections are mostly a one-way data flow - relay agent sends a > request, server sends lots of responses. > > TCP is great, don't get me wrong, but sometimes you need faster > response > than it offers. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, December 17, 2008 12:04 AM > To: Bernie Volz (volz) > Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; > IESG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > Why would a broken TCP connection stay up for 10 minutes? Shouldn't > it die within 90 seconds if no ACKs are forthcoming from the remote > end? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 05:58:39 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E5628C18D; Wed, 17 Dec 2008 05:58:39 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78D63A6B21; Wed, 17 Dec 2008 05:58:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DQv7vwjeqOD; Wed, 17 Dec 2008 05:58:32 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 83ED33A6B20; Wed, 17 Dec 2008 05:58:32 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBHDupHB010087; Wed, 17 Dec 2008 06:56:51 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBHDwObS124420; Wed, 17 Dec 2008 06:58:24 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBHDwOgT004060; Wed, 17 Dec 2008 06:58:24 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-129-16.mts.ibm.com [9.76.129.16]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBHDwLKV004014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 06:58:23 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBHDp0Tg031488; Wed, 17 Dec 2008 08:56:20 -0500 Message-Id: <200812171356.mBHDp0Tg031488@cichlid.raleigh.ibm.com> To: "Bernie Volz (volz)" In-reply-to: <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> Comments: In-reply-to "Bernie Volz (volz)" message dated "Tue, 16 Dec 2008 23:30:01 -0500." Date: Wed, 17 Dec 2008 08:51:00 -0500 From: Thomas Narten Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Maybe I'm dense, but I still don't get it. > If the information isn't available, the relay agent will attempt to > recover what it can and go one -- possibly doing individual UDP > leasequery as needed to recover leases. This scares me. If TCP doesn't work, retrying to the *SAME* server using UDP isn't the right way to fix the problem. Indeed, why would UDP work if TCP doesn't? Exactly what type of failure/scenario are you concerned about? Can you please describe a scenario where retrying using UDP actually makes sense? As others have indicated, I still don't get the actual problem, and how the suggested workarounds actually address the problem. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 05:58:42 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCDB28C1D4; Wed, 17 Dec 2008 05:58:42 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6772C3A6B22; Wed, 17 Dec 2008 05:58:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4fePsEHDoCz; Wed, 17 Dec 2008 05:58:40 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 1ECDA3A6452; Wed, 17 Dec 2008 05:58:40 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBHDvJsW016457; Wed, 17 Dec 2008 06:57:19 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBHDwUkb209270; Wed, 17 Dec 2008 06:58:30 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBHDwTo3003112; Wed, 17 Dec 2008 06:58:29 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-129-16.mts.ibm.com [9.76.129.16]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBHDwQl4002983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 06:58:28 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBHDn5ce031396; Wed, 17 Dec 2008 08:54:25 -0500 Message-Id: <200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com> To: "Bernie Volz (volz)" In-reply-to: <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> Comments: In-reply-to "Bernie Volz (volz)" message dated "Tue, 16 Dec 2008 23:30:01 -0500." Date: Wed, 17 Dec 2008 08:49:05 -0500 From: Thomas Narten Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Maybe I'm dense, but I still don't get it. > If the information isn't available, the relay agent will attempt to > recover what it can and go one -- possibly doing individual UDP > leasequery as needed to recover leases. This scares me. If TCP doesn't work, retrying to the *SAME* server using UDP isn't the right way to fix the problem. Indeed, why would UDP work if TCP doesn't? Exactly what type of failure/scenario are you concerned about? Can you please describe a scenario where retrying using UDP actually makes sense? As others have indicated, I still don't get the actual problem, and how the suggested workarounds actually address the problem. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 09:09:39 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D6728C170; Wed, 17 Dec 2008 09:09:39 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08E53A6AF1; Wed, 17 Dec 2008 09:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re0pShIoINQ5; Wed, 17 Dec 2008 09:09:36 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D1AF43A6938; Wed, 17 Dec 2008 09:09:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,238,1228089600"; d="scan'208";a="124288182" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 17 Dec 2008 17:09:29 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBHH9S5J023511; Wed, 17 Dec 2008 12:09:28 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHH9Sl8029347; Wed, 17 Dec 2008 17:09:28 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 12:09:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 12:09:21 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclgT5Z2xGaY4e4+Rj+R9RUkgbF8ogAGMaKg References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com> From: "Bernie Volz (volz)" To: "Thomas Narten" X-OriginalArrivalTime: 17 Dec 2008 17:09:28.0719 (UTC) FILETIME=[387B89F0:01C9606A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3475; t=1229533768; x=1230397768; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Thomas=20Narten=22=20; bh=JuxcbRr4e8BCXkt5glvabZ2KUuwqaSsI+UxJ2ahek2I=; b=xlm5oXSHDsWxWagQu5OBkYSUKexrLFoKradskU5xMWGGkXrl2X+11u1Fv0 Pm7daAop25xHlxCol500EhGRA/dUkd+FYMrUuyyyyTgAxFJgXXkeQqLI159s A82OuB35Kl; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thomas: The TCP connection (bulk leasequery) is designed to recover all of the leases quickly. The UDP leasequery is used when a packet arrives that a router (typically CMTS which is both a router and relay agent) has no information for (ie, it doesn't know which client behind which CM is using that address). In this case, it asks the DHCP server (via a UDP leasequery) about that individual lease (query by address). This happens, on demand, when traffic arrives. This is the ONLY recovery technique that exists today. The rate at which these requests are generated is limited by traffic arrival (and hopefully rate limiting). Once information is known (either via TCP bulk LQ or UDP LQ), no further queries are needed. The problem with DHCPv6 is that if prefix delegation is being used and the CMTS (router) is also advertising those routes in order for traffic to get there, no traffic will arrive until the PD data is recovered and the routers advertised. Therefore, the UDP based leasequery can't be used since the relay agent/router has no idea what to request. The general model is that likely BOTH TCP (for bulk and PD) and UDP (on demand when no information exists) leasequery would be used. While bulk (TCP) is loading the configuration, traffic may arrive and thus generate a UDP LQ as well. TCP is only used to seed the information initially -- after successful bulk LQ, future information is learn by monitoring DHCPv6 traffic. The UDP LQ are extremely efficient -- after all, the DHCP server is all about address management and looking up an address is very easy and quick for it. If the server is down, what difference does it make if TCP or UDP are being used? Sure, traffic is being generated, but it isn't going to be answered. In which case, the relay will not have information and be forced to drop packets on the floor. If the relay only relied on TCP, it would be forced to wait until potentially ALL data was downloaded (it may be the last lease that is the one needed "now"). And, remember that bulk LQ does not yet exist -- so UDP is being used today. Also, remember that this is all between components (relay agents/routers and DHCP servers) and not thousands of users on the Internet. Traffic provision in an operators' network needs to accommodate this. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Wednesday, December 17, 2008 8:49 AM To: Bernie Volz (volz) Cc: Dhcwg; Mark Stapp (mjs); Lars Eggert; IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Maybe I'm dense, but I still don't get it. > If the information isn't available, the relay agent will attempt to > recover what it can and go one -- possibly doing individual UDP > leasequery as needed to recover leases. This scares me. If TCP doesn't work, retrying to the *SAME* server using UDP isn't the right way to fix the problem. Indeed, why would UDP work if TCP doesn't? Exactly what type of failure/scenario are you concerned about? Can you please describe a scenario where retrying using UDP actually makes sense? As others have indicated, I still don't get the actual problem, and how the suggested workarounds actually address the problem. Thomas _______________________________________________ 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 dhcwg-bounces@ietf.org Wed Dec 17 09:51:11 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52AB13A6B23; Wed, 17 Dec 2008 09:51:11 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7C23A6B20 for ; Wed, 17 Dec 2008 09:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e40u8IhUYOB for ; Wed, 17 Dec 2008 09:51:08 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 647283A6B21 for ; Wed, 17 Dec 2008 09:51:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,238,1228089600"; d="scan'208";a="116378173" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 17 Dec 2008 17:51:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBHHp0FU013035; Wed, 17 Dec 2008 12:51:00 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHHox1U012664; Wed, 17 Dec 2008 17:51:00 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 12:50:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 12:50:25 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C495@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <28C7C5C4-A88B-4875-ADF7-AE6CBC622FF9@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclgaxaLEWSXTxqLR0+NDklNoT3FqgAA6DaA References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> <15E4F3E9-EC00-4D47-981E-D16134552B15@nominum.com> <8E296595B6471A4689555D5D725EBB2109F3C295@xmb-rtp-20a.amer.cisco.com> <15B7220C-B885-4D0C-B0F3-E5F9AB381AB4@nominum.com> <8E296595B6471A4689555D5D725EBB2109F3C448@xmb-rtp-20a.amer.cisco.com> <28C7C5C4-A88B-4875-ADF7-AE6CBC622FF9@nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" X-OriginalArrivalTime: 17 Dec 2008 17:50:59.0937 (UTC) FILETIME=[055D3D10:01C96070] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2075; t=1229536260; x=1230400260; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Ted=20Lemon=22=20; bh=l9gQJCnJKfygzb4NraacqNrwO9cz95EiG/TKlxjbGCA=; b=YzFnqWFgsGSsHKYv1W6heOFdwnMwiyR+SSAyMafy/GjBGG7t+i2EF2I0+Z kvfgsLyZlGQYZO3lloPEwt2uQPXVVOnfKYW2otWSOP4W2tsr0WVDvb3I0L6q 6V5IdidM46; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Thomas Narten , Dhcwg , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Sorry to add DHC WG and a few others but I think this is important to this discussion ... --- If enabled. I also think that the time frame is much longer than 180 seconds -- more like 9 minutes on most Unix implementations, but read on! My experience with TCP (I actually implemented a stack in the 1980s - 1990s -- it was NOT BSD derived as most implementations are, but home grown) does date back about 10 years now. But as I recall, keepalives tended to keep connections alive for long periods as they were designed to survive short term network outages -- here we are taking minutes, not seconds or days. And, RFC 1122 has: 4.2.3.6 TCP Keep-Alives Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off. Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the --> connection within an interval. This interval MUST be --> configurable and MUST default to no less than two hours. So, we have no less than 2 HOURS as the MUST default!! A relay agent would not want to wait 2 hours to recover from this condition. A DHCP server also may well chose not to leave open a connection for 2 hours. Neither of these actions are banned. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, December 17, 2008 12:15 PM To: Bernie Volz (volz) Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review On Dec 17, 2008, at 11:10 AM, Bernie Volz (volz) wrote: > Client sends request ... Received by server. Server crashes before > sending a single byte as a response. No data is flowing. Hm, okay. So in this case wouldn't keepalives kill the connection after a maximum of 180 seconds? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 11:51:41 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53A93A6AEA; Wed, 17 Dec 2008 11:51:41 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32A13A6AEA for ; Wed, 17 Dec 2008 11:51:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5hxfluC-803 for ; Wed, 17 Dec 2008 11:51:40 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 1B3C63A68AA for ; Wed, 17 Dec 2008 11:51:40 -0800 (PST) Received: from david.isc.org (c-67-161-50-42.hsd1.ca.comcast.net [67.161.50.42]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBHJpVIo028205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Dec 2008 11:51:32 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 7DD6F16E1B3; Wed, 17 Dec 2008 11:51:30 -0800 (PST) Date: Wed, 17 Dec 2008 11:51:30 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081217195129.GA6362@isc.org> References: <52AB41B5-F8FC-4EA7-BB13-2DAF91618715@cisco.com> <8E296595B6471A4689555D5D725EBB2109F3C263@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB2109F3C263@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1909736945==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1909736945== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 17, 2008 at 12:48:03AM -0500, Bernie Volz (volz) wrote: > 2. For v6 (could also be an issue for v4), what happens if the > client/relay provides this option in the ORO (PRL)? And, should the > client/relay, if it wants it sent back, include it in the ORO (PRL)? > Perhaps we consider this a "core" protocol option (similar to the IA_NA, > IA_PD, IA_TA) where the option is not required to be in the ORO (PRL) as > the semantics require the server to send it back if received. ERO? I'm not sure if there are existing implementations we're working with either. This was an RFC 3942 action that intended standards track instead of informational... For DHCPv6 relay agents we have a curious situation as well. The relay agent's request option is the ERO; but this implies only echoing the relay's prior contents. Should the relay agent provide an ORO if it expects a VPN assignment, and ERO if it expects to assign the VPN? --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFJSVhBcXeLeWu2vmoRArDFAJ0Znnlnh3RLY5iWsRyNnGwBXX/oEwCeKHcX YtmbWWYte8gSTlmTAHFSRR0= =cbz2 -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- --===============1909736945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1909736945==-- From dhcwg-bounces@ietf.org Wed Dec 17 13:11:55 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A226A3A6973; Wed, 17 Dec 2008 13:11:55 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6813A68D3; Wed, 17 Dec 2008 13:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04sE4xDpZde6; Wed, 17 Dec 2008 13:11:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C94D03A6831; Wed, 17 Dec 2008 13:11:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,239,1228089600"; d="scan'208,217";a="31367828" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Dec 2008 21:11:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBHLBVwQ027225; Wed, 17 Dec 2008 16:11:31 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBHLBUCM011008; Wed, 17 Dec 2008 21:11:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 16:11:30 -0500 Received: from [10.86.249.137] ([10.86.249.137]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 16:11:30 -0500 Message-ID: <49496B01.20103@cisco.com> Date: Wed, 17 Dec 2008 16:11:29 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thomas Narten References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <200812171356.mBHDp0Tg031488@cichlid.raleigh.ibm.com> In-Reply-To: <200812171356.mBHDp0Tg031488@cichlid.raleigh.ibm.com> X-OriginalArrivalTime: 17 Dec 2008 21:11:30.0322 (UTC) FILETIME=[08084F20:01C9608C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3274; t=1229548291; x=1230412291; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20Thomas=20Narten=20; bh=o3hq9sK0oqk0XKHgWo/sx6OSsuTOmdDEdc96+3P5W9I=; b=IlN1EV+xE+D06K4JfQCrBceT5+BtqpiQ+vf1lhHc5K2Tj6SCqzeX6BN7/t e4rI6m97b9PZQcKg/v6iI7HFMXv1/XVICZeAdzGzvHufwug3ULGAznbx2GUa H63E4S4XGZ; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , "Bernie Volz \(volz\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0506453449==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0506453449== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The motivation for offering administrative controls has been to allow the client (a dhcp relay) to notice a condition in a deterministic way. Having noticed the condition - which might be a failure to connect in a timely way, or a failure to receive a timely answer to a query - the relay can do _something_. The objection seems to be about what it can do, as the draft is written now - correct?

The concrete objections seem to be:

1. allowing a relay to terminate a connection attempt, and then attempt to reconnect. the objection is that this fails to take advantage of TCP's own retry mechanisms.

2. allowing a relay to attempt UDP, one-at-a-time queries if it determines that the TCP, bulk query is not succeeding.

I do think case 2 is valid. it's possible that a server may be under TCP DOS attack for example, or it may have reached a limit in the number of TCP lease queries it's willing to accept and process in parallel. in either of those cases, a server may be willing and able to process a lighter-weight, single query. I don't think that's a highly-likely case, but I think it's legitimate, and there's no reason to "forbid" it.

I think case 1 is a little subtle, but I'm willing to try to change the text about connection attempts. I'd like to say that there's no benefit to terminating a TCP connection attempt and retrying it. A relay may take action after the draft's connection timeout - it may try to connect to another server, or it may just signal the condition or write to its log. but the relay shouldn't abandon the connection attempt if TCP hasn't signalled a connection failure and if it intends to retry the same server again.

Would that help - Thomas? Lars?

Thanks,
Mark

Thomas Narten wrote: 
Maybe I'm dense, but I still don't get it.

  
If the information isn't available, the relay agent will attempt to
recover what it can and go one -- possibly doing individual UDP
leasequery as needed to recover leases.
    

This scares me. If TCP doesn't work, retrying to the *SAME* server
using UDP isn't the right way to fix the problem. Indeed, why would
UDP work if TCP doesn't? Exactly what type of failure/scenario are you
concerned about?

Can you please describe a scenario where retrying using UDP actually
makes sense?

As others have indicated, I still don't get the actual problem, and
how the suggested workarounds actually address the problem.

Thomas
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--===============0506453449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0506453449==-- From dhcwg-bounces@ietf.org Wed Dec 17 14:05:40 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21D73A6B4C; Wed, 17 Dec 2008 14:05:40 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EFA3A6B49; Wed, 17 Dec 2008 14:05:39 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36l2XzOZ9s-u; Wed, 17 Dec 2008 14:05:38 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 1AE453A67D2; Wed, 17 Dec 2008 14:05:37 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBHM4gUo012226; Wed, 17 Dec 2008 17:04:42 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBHM5TdK154244; Wed, 17 Dec 2008 17:05:29 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBHN5dMC022654; Wed, 17 Dec 2008 18:05:39 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-153-206.mts.ibm.com [9.76.153.206]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBHN5cYc022538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 18:05:39 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBHM5RST029771; Wed, 17 Dec 2008 17:05:27 -0500 Message-Id: <200812172205.mBHM5RST029771@cichlid.raleigh.ibm.com> To: "Bernie Volz (volz)" In-reply-to: <8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com> References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com> <8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com> Comments: In-reply-to "Bernie Volz (volz)" message dated "Wed, 17 Dec 2008 12:09:21 -0500." Date: Wed, 17 Dec 2008 17:05:27 -0500 From: Thomas Narten Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie, thanks again for the long explanation. I have no issue with the scenario you describe. > The TCP connection (bulk leasequery) is designed to recover all of the > leases quickly. > The UDP leasequery is used when a packet arrives that a router > (typically CMTS which is both a router and relay agent) has no > information for (ie, it doesn't know which client behind which CM is > using that address). In this case, it asks the DHCP server (via a UDP > leasequery) about that individual lease (query by address). This > happens, on demand, when traffic arrives. This is the ONLY recovery > technique that exists today. The rate at which these requests are > generated is limited by traffic arrival (and hopefully rate limiting). > Once information is known (either via TCP bulk LQ or UDP LQ), no further > queries are needed. So, the usage of TCP vs. UDP is completely unrelated. That is, you don't start with TCP and then if that fails, try UDP or anything like that. Rather, on system restart, you use TCP, because you are trying to restore lost state. If, while you are waiting, you happen to get a packet you don't know what to do with, you issue a UDP query just for the one address. That seems fine, since this is what you do normally, independent of whether any TCP query is happening in background. An important point here is that there is no need to tie the UDP & TCP behavior together - they are logicially independent, invoked at mostly unrelated times. My recommendation would be to just keep the two usages separate and avoid saying things that make people think that if TCP fails, you need to failover to using UDP. You don't. (An earlier message suggested that.) But, that does again raise the question of what do you do if TCP "fails"? You presumably do either nothing (in which case terminating the TCP connection early seems pointless), or you restart the TCP query (because you still have to restore all that missing state, and UDP queries can't do that... you only use UDP for specific, narrow queries). Again, IMO, you should only restart the TCP connection if you have good reason to think that retrying would help. It would go against long-standing IETF practice to try to restart more aggressively than TCP already does. IMO, you need a compelling argument to go down this path. So I just don't think you need to terminate a TCP connection early. I don't see how that helps the relay agent at all. I would just describe the two usages separately and not tie them together. > The general model is that likely BOTH TCP (for bulk and PD) and UDP (on > demand when no information exists) leasequery would be used. While bulk > (TCP) is loading the configuration, traffic may arrive and thus generate > a UDP LQ as well. TCP is only used to seed the information initially -- > after successful bulk LQ, future information is learn by monitoring > DHCPv6 traffic. Works for me. > The UDP LQ are extremely efficient -- after all, the DHCP server is all > about address management and looking up an address is very easy and > quick for it. > If the server is down, what difference does it make if TCP or UDP are > being used? Sure, traffic is being generated, but it isn't going to be > answered. Well, I would argue that you might well want to think about rate limiting UDP lease queries generally. Consider a DOS attack using addresses in a packet that the CMTS gets. Do you really want the CMTS pounding on the server for *each* of those packets? Or, consider when it gets a train of legitimate TCP packets from a (pre-existing) bittorrent connection.. Do you want each packet to cause a UDP query to the server? I would think not... I.e., the same issue happens with ARP/ND, and they are typically rate limited to prevent storms in this scenario... > In which case, the relay will not have information and be > forced to drop packets on the floor. If the relay only relied on TCP, it > would be forced to wait until potentially ALL data was downloaded (it > may be the last lease that is the one needed "now"). And, remember that > bulk LQ does not yet exist -- so UDP is being used today. So one thing I don't quite get. You said earlier that in some cases, UDP is insufficient because traffic won't arrive at the CMTS to generate the query. Hence, Bulk Query is needed. But here you say, Bulk Query isn't deployed yet. Does that mean that current deployed technology/standards has real holes (i.e,. lead to permanent failures)? > Also, remember that this is all between components (relay agents/routers > and DHCP servers) and not thousands of users on the Internet. Traffic > provision in an operators' network needs to accommodate this. I hear you, but that argument has the problem that no technology controls where it gets used in practice, so its not good for our protocols to rely on this for proper behavior. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 14:08:02 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308373A6B45; Wed, 17 Dec 2008 14:08:02 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CBA3A6B45 for ; Wed, 17 Dec 2008 14:08:00 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYTUxoMQSai1 for ; Wed, 17 Dec 2008 14:07:59 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2D4DB3A67D2 for ; Wed, 17 Dec 2008 14:07:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,239,1228089600"; d="scan'208";a="31411005" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Dec 2008 22:07:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBHM7n43026388 for ; Wed, 17 Dec 2008 17:07:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHM7nH8008567 for ; Wed, 17 Dec 2008 22:07:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 17:07:49 -0500 Received: from kkinnear-wxp01.cisco.com ([161.44.65.110]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 17:07:48 -0500 Message-Id: <4.3.2.7.2.20081217165359.0378bb40@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Dec 2008 17:08:05 -0500 To: Ralph Droms , dhc WG From: Kim Kinnear In-Reply-To: <18DF2820-737D-483B-A7FE-9972C94E8210@cisco.com> Mime-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2008 22:07:48.0941 (UTC) FILETIME=[E5D8A7D0:01C96093] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3954; t=1229551669; x=1230415669; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20REMINDER=3A=20dhc=20WG=20last =20call=20on=0A=20=20draft-ietf-dhc-relay-id-suboption-04.tx t |Sender:=20 |To:=20Ralph=20Droms=20,=20dhc=20WG=20; bh=gZRbbLr/4l0geoerirI+u71ScaeCS/ZUQjJjn4QNKcE=; b=PV0M1YgfzhOSBU5nsjyu60DH5EupMqs8ba1kHCPpIOXPRCK5a34SSzxID7 gUNvXfJI9A/63qyoCbkU73BRMV17lAgF84v7bytUf7JIAbeDI3iXYDd3GP/6 134L+X5JSK; Authentication-Results: rtp-dkim-2; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: kkinnear@cisco.com Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph, et. al. I have performed a detailed review of this document as I agreed to do when we met in Minneapolis. Since this was just re-issued as an -05.txt version, I reviewed the -05.txt version. It is acceptable as it is, and the several comments that I make below aren't intended to hold up the document's progress. If we can get some of these points addressed during some of the editing passes that are ahead, that would be nice but not required. 1. In section 3.2, Bulk Leasequery, the world has moved on since these words were written. There is currently a draft-kkinnear-dhc-dhcpv4-bulk-leasequery-01.txt which is the merged version of the two drafts mentioned in the draft under review. I believe that it has been successfully accepted as a work item for the DHC WG, and thus the next version (which will be out as soon as I fold in current comments) will be draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt. You could reference that now, or the draft-kkinnear.*-01.txt one, but it would be nice to only reference one draft since they have now merged. 2. In section 5, Relay Identifier Types, it would be useful to simply include a table with the defined numeric values for RELAY_IDENTIFIER_DUID and RELAY_IDENTIFIER_ASCII. IANA isn't going to change these values, and it seems difficult (and unusual) to send the implementor off to the IANA section to find the actual values of these constants. 3. In section 7, Identifier Stability, it might be useful to discuss something about Identifier Continuity in the context of stability. You have used the Industrial Ethernet as a use case (which I think was a good idea), and one of the difficulties of this particular use case is what to do when a relay agent has to be replaced. This would seem to be the place to specify some behavior as to how to handle one device taking over for a failed device. It would seem to me that allowing (or requiring) devices to be able to generate a DUID that matches that of a previous plug-compatible (or at least port-compatible) device might be useful here. Other than those non-required changes, I found no problems with the document and feel it should move forward in the standardization process. Regards -- Kim At 05:51 AM 12/16/2008, Ralph Droms wrote: >REMINDER: This WG last call will end on Dec 19. We have only received >one review of the document, and need several more reviews before the >document can be advanced to the IESG. > >This message announces a WG last call on "The DHCPv4 Relay Agent >Identifier Suboption" . The >last call will conclude at 1700PDT on December 19, 2008. This >document is intended for publication as a Proposed Standard. The -04 >revision of the document includes changes based on the comments >received during the previous last call. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. Lack of discussion does not >represent positive support. If there is no expression of support for >acceptance during the WG last call, the document will not be advanced >to the IESG. > >draft-ietf-dhc-relay-id-suboption-04.txt defines a new Relay Agent >Identifier suboption for the Dynamic Host Configuration Protocol's >(DHCP) Relay Agent Information option. The suboption carries a unique >identifier configured or generated at the relay agent. The suboption >allows a DHCP relay agent to include the unique identifier in the DHCP >messages it sends. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-04.txt > >- John Brzozowski, Ralph Droms > dhc WG chairs > >_______________________________________________ >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 dhcwg-bounces@ietf.org Wed Dec 17 14:17:20 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9FC28C1E5; Wed, 17 Dec 2008 14:17:20 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055DB28C1CA; Wed, 17 Dec 2008 14:17:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osnZJdJ6moEd; Wed, 17 Dec 2008 14:17:18 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 2916F3A6B46; Wed, 17 Dec 2008 14:17:18 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBHMGqou032329; Wed, 17 Dec 2008 17:16:52 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBHMH9jr170552; Wed, 17 Dec 2008 17:17:09 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBHMH9Lu006424; Wed, 17 Dec 2008 17:17:09 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-153-206.mts.ibm.com [9.76.153.206]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBHMH8Y7006395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 17:17:08 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBHMH6PB030073; Wed, 17 Dec 2008 17:17:07 -0500 Message-Id: <200812172217.mBHMH6PB030073@cichlid.raleigh.ibm.com> To: "Bernie Volz (volz)" In-reply-to: <8E296595B6471A4689555D5D725EBB2109F3C296@xmb-rtp-20a.amer.cisco.com> References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> <8E296595B6471A4689555D5D725EBB2109F3C296@xmb-rtp-20a.amer.cisco.com> Comments: In-reply-to "Bernie Volz (volz)" message dated "Wed, 17 Dec 2008 08:26:24 -0500." Date: Wed, 17 Dec 2008 17:17:06 -0500 From: Thomas Narten Cc: "Mark Stapp \(mjs\)" , IESG , Lars Eggert , Dhcwg , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > 2. Responses (from the server to relay) have stopped being sent because > the server is not there. Well, this seems like a pretty narrow edge case. I.e., you just opened a connection to the server, then before the server actually starting sending data, it crashes. This can happen with *ANY* protocol today. But it doesn't happen very often, and I can think of few protocols that actually worry about this case. I.e., we are talking of a window of a second or less, in most cases. Is it *really* that important to handle this case in your scenario? And how quickly would you need to detect this? (And the question of *how* would you respond to this event after detection is still unclear, IMO.) Anyway, a better way to deal with that is to (at the application layer) add a specific "are you still there" ping/reply liveness test (across TCP). You could do that at the application level pretty easily. But it seems like overkill to me. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 14:34:00 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0C828C1F0; Wed, 17 Dec 2008 14:34:00 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0334528C1BB; Wed, 17 Dec 2008 14:33:59 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-KKUH3d1qHt; Wed, 17 Dec 2008 14:33:58 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id A3AD328C1E1; Wed, 17 Dec 2008 14:33:51 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSUl+R5LmlZ7qrN3nhvsSJAoBicP0uM3k@postini.com; Wed, 17 Dec 2008 14:33:51 PST 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 shell-too.nominum.com (Postfix) with ESMTP id 50DB11B823F; Wed, 17 Dec 2008 14:33:53 -0800 (PST) Received: from [64.89.227.148] (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 17 Dec 2008 14:33:42 -0800 Message-ID: <8D574203-4BBB-45A1-9F29-B25E18A41948@nominum.com> From: Ted Lemon To: Thomas Narten In-Reply-To: <200812172217.mBHMH6PB030073@cichlid.raleigh.ibm.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 16:33:38 -0600 References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> <8E296595B6471A4689555D5D725EBB2109F3C296@xmb-rtp-20a.amer.cisco.com> <200812172217.mBHMH6PB030073@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.930.3) Cc: "Bernie Volz \(volz\)" , IESG , Lars Eggert , Dhcwg , "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Dec 17, 2008, at 4:17 PM, Thomas Narten wrote: > Anyway, a better way to deal with that is to (at the application > layer) add a specific "are you still there" ping/reply liveness test > (across TCP). You could do that at the application level pretty > easily. But it seems like overkill to me. The problem with doing this is that in the scenario Bernie's talking about, you've already sent a request, and there's no protocol for sending another one until the response to the first request comes back. And if your platform doesn't support keepalives, or doesn't allow you to control the keepalive interval, then the protocol is simply wedged until such time as the relay is rebooted. So even though it's an unlikely case, it matters because it causes a fairly serious problem. It seems to me that in this case it makes sense to propose that if after a request has been transmitted, if no response is heard for some period of minutes, the requester should break the connection and try again. But there's no need to set the tolerances shorter than the TCP timeout interval, at least as far as I can see. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 15:09:56 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B9428C1EC; Wed, 17 Dec 2008 15:09:56 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDA33A688C; Wed, 17 Dec 2008 15:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzPtnRDh5ezh; Wed, 17 Dec 2008 15:09:54 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 334893A6768; Wed, 17 Dec 2008 15:09:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,239,1228089600"; d="scan'208";a="31417348" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Dec 2008 23:09:46 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBHN9kaZ015184; Wed, 17 Dec 2008 18:09:46 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBHN9knT026356; Wed, 17 Dec 2008 23:09:46 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 18:09:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 18:09:40 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C708@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <200812172205.mBHM5RST029771@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: Aclgk5W+CbxFBvfGQTyO6WZKn8oGpAABIDEA References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com> <8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com> <200812172205.mBHM5RST029771@cichlid.raleigh.ibm.com> From: "Bernie Volz (volz)" To: "Thomas Narten" X-OriginalArrivalTime: 17 Dec 2008 23:09:46.0296 (UTC) FILETIME=[8D900380:01C9609C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11382; t=1229555386; x=1230419386; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Thomas=20Narten=22=20; bh=cES0D21XI9g8vsMkNSlHAzhvHR1hB+tUF6yVtv5BWqs=; b=aSl/kGZ0+OAm8ooOQ7hu4d7iNeOqXbH+6Za27pVpRmW/4qkDFt7spwG7MV aGhGUgLuDfjBNpB4s98RnVT3QDYHdp92FiNOhXYP9u9vnoYHgv0PowSJLnu0 ylsIiQEasr; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >My recommendation would be to just keep the two usages separate and >avoid saying things that make people think that if TCP fails, you need >to failover to using UDP. You don't. (An earlier message suggested >that.) I think the earlier message was just trying to convey this. I don't believe the I-D actually says any such thing (I took a quick look and didn't see anything like this, but perhaps I missed it). >Well, I would argue that you might well want to think about rate >limiting UDP lease queries generally. Consider a DOS attack using Rate limiting is always a good idea (for UDP). This would be an issue for RFC 5007 (and 4388 for DHCPv4). In the RFC 5007 in the security considerations we have: Since even trusted access concentrators may generate LEASEQUERY requests as a result of activity external to the access concentrator, access concentrators SHOULD minimize potential denial-of-service attacks on the DHCPv6 servers by minimizing the generation of LEASEQUERY messages. In particular, the access concentrator SHOULD employ negative caching (i.e., cache the fact that a particular recent query failed to return client data) and address restrictions where possible (i.e., don't send a LEASEQUERY message for addresses outside the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to transmitting one LEASEQUERY message (excluding message retries) per legitimate broadband access network address after a reboot event. Packet-flooding denial-of-service attacks can result in the exhaustion of processing resources, thus preventing the server from serving legitimate and regular DHCPv6 clients as well as legitimate DHCPv6 LEASEQUERY requestors, denying configurations to legitimate DHCPv6 clients as well lease information to legitimate DHCPv6 LEASEQUERY requestors. While these attacks are unlikely when only communicating with trusted LEASEQUERY requestors, the possibility always exists that the trust is misplaced, security techniques are compromised, or even trusted requestors can have bugs in them. Therefore, techniques for defending against packet-flooding denial of service are always a good idea, and they include good perimeter security, as mentioned earlier, and rate limiting DHCPv6 traffic by relay agents, other network elements, or the server itself. So, I think this issue is pretty well covered there? >So one thing I don't quite get. You said earlier that in some cases, >UDP is insufficient because traffic won't arrive at the CMTS to >generate the query. Hence, Bulk Query is needed. But here you say, >Bulk Query isn't deployed yet. Does that mean that current deployed >technology/standards has real holes (i.e,. lead to permanent >failures)? We've worked on this issue with the RAAN proposal (draft-droms-dhc-dhcpv6-agentopt-delegate which has expired). This is really only an issue with Prefix Delegation (RFC 3633), and when non-aggregated prefixes are delegated. This probably hasn't been common yet since it is a missing piece to recover these leases. UDP LQ (RFC 5007) can be used to recover the prefix delegations, but only if traffic is received that has an address contained by a delegated prefix. But, if the prefix needs to be advertised before traffic is received ... There's a catch-22. Hence, one of the key reasons Bulk LQ is required. An alternative is to use some routing protocol between the requesting and delegating router. I think there really are two key issues for Bulk LQ with respect to the TCP connections: 1. Requestor (relay agent) - if a request was initiated but responses are not furthcoming in a "timely" fashion. There are three primary causes: A) The server is unable to communicate -- it is down. B) The network prevents communication. C) The server is "slow" (busy) and not responding in a timely fashion. A is clearly the one that is important to detect. But, it is often difficult to distinguish between the three. Clearly a timeout is appropriate here as TCP could allow a long period of time (hours) to go by before reporting a problem. A user would generally give up (of course, a user would likely use recent experience to determine whether the wait is appropriate or not). 2. Server - if a connection is open but no outstanding request exists on it. After some period of time, a server is again within its right to close the connection to "conserve" resources. I believe the main concern is not about disallowing the above actions, but what is a reasonable time period to allow TCP "to do its thing" and avoid re-doing work by reopening a connection and repeating a request (perhaps with the same result). In particular the following parameters are the issue: Parameter Default Description ------------------------------------------ BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout I suspect that removing BULK_LQ_CONN_TIMEOUT would be fine as TCP already handles this (usually with a 90 second timeout). The BULK_LQ_MAX_RETRY parameter (60 seconds) I don't think should be an issue -- waiting at most a minute before retrying to connects seems reasonable, as recovering the data quickly is a goal and thus waiting too long prevents that. For BULK_LQ_DATA_TIMEOUT, 30 seconds is likely too short. Making this several minutes would be far better. Perhaps a value of 5 minutes would be a reasonable default, with recommendations not to make it too short as it prevents TCP from doing its thing. While larger values are also possible, I think if it takes 5 minutes to get data through, something is very wrong and there are bigger issues (retrying the connection with the same result is not going to cost a lot every 5 minutes). (If a user where initiating this, I suspect they would long have given up -- do you wait 5 minutes to a web page to load??) - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, December 17, 2008 5:05 PM To: Bernie Volz (volz) Cc: Dhcwg; Mark Stapp (mjs); Lars Eggert; IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Bernie, thanks again for the long explanation. I have no issue with the scenario you describe. > The TCP connection (bulk leasequery) is designed to recover all of the > leases quickly. > The UDP leasequery is used when a packet arrives that a router > (typically CMTS which is both a router and relay agent) has no > information for (ie, it doesn't know which client behind which CM is > using that address). In this case, it asks the DHCP server (via a UDP > leasequery) about that individual lease (query by address). This > happens, on demand, when traffic arrives. This is the ONLY recovery > technique that exists today. The rate at which these requests are > generated is limited by traffic arrival (and hopefully rate limiting). > Once information is known (either via TCP bulk LQ or UDP LQ), no further > queries are needed. So, the usage of TCP vs. UDP is completely unrelated. That is, you don't start with TCP and then if that fails, try UDP or anything like that. Rather, on system restart, you use TCP, because you are trying to restore lost state. If, while you are waiting, you happen to get a packet you don't know what to do with, you issue a UDP query just for the one address. That seems fine, since this is what you do normally, independent of whether any TCP query is happening in background. An important point here is that there is no need to tie the UDP & TCP behavior together - they are logicially independent, invoked at mostly unrelated times. My recommendation would be to just keep the two usages separate and avoid saying things that make people think that if TCP fails, you need to failover to using UDP. You don't. (An earlier message suggested that.) But, that does again raise the question of what do you do if TCP "fails"? You presumably do either nothing (in which case terminating the TCP connection early seems pointless), or you restart the TCP query (because you still have to restore all that missing state, and UDP queries can't do that... you only use UDP for specific, narrow queries). Again, IMO, you should only restart the TCP connection if you have good reason to think that retrying would help. It would go against long-standing IETF practice to try to restart more aggressively than TCP already does. IMO, you need a compelling argument to go down this path. So I just don't think you need to terminate a TCP connection early. I don't see how that helps the relay agent at all. I would just describe the two usages separately and not tie them together. > The general model is that likely BOTH TCP (for bulk and PD) and UDP (on > demand when no information exists) leasequery would be used. While bulk > (TCP) is loading the configuration, traffic may arrive and thus generate > a UDP LQ as well. TCP is only used to seed the information initially -- > after successful bulk LQ, future information is learn by monitoring > DHCPv6 traffic. Works for me. > The UDP LQ are extremely efficient -- after all, the DHCP server is all > about address management and looking up an address is very easy and > quick for it. > If the server is down, what difference does it make if TCP or UDP are > being used? Sure, traffic is being generated, but it isn't going to be > answered. Well, I would argue that you might well want to think about rate limiting UDP lease queries generally. Consider a DOS attack using addresses in a packet that the CMTS gets. Do you really want the CMTS pounding on the server for *each* of those packets? Or, consider when it gets a train of legitimate TCP packets from a (pre-existing) bittorrent connection.. Do you want each packet to cause a UDP query to the server? I would think not... I.e., the same issue happens with ARP/ND, and they are typically rate limited to prevent storms in this scenario... > In which case, the relay will not have information and be > forced to drop packets on the floor. If the relay only relied on TCP, it > would be forced to wait until potentially ALL data was downloaded (it > may be the last lease that is the one needed "now"). And, remember that > bulk LQ does not yet exist -- so UDP is being used today. So one thing I don't quite get. You said earlier that in some cases, UDP is insufficient because traffic won't arrive at the CMTS to generate the query. Hence, Bulk Query is needed. But here you say, Bulk Query isn't deployed yet. Does that mean that current deployed technology/standards has real holes (i.e,. lead to permanent failures)? > Also, remember that this is all between components (relay agents/routers > and DHCP servers) and not thousands of users on the Internet. Traffic > provision in an operators' network needs to accommodate this. I hear you, but that argument has the problem that no technology controls where it gets used in practice, so its not good for our protocols to rely on this for proper behavior. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 17 17:07:51 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E3D28C1E8; Wed, 17 Dec 2008 17:07:51 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6F03A6B56; Wed, 17 Dec 2008 17:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lQM0dKi4AGy; Wed, 17 Dec 2008 17:07:49 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 854703A66B4; Wed, 17 Dec 2008 17:07:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,240,1228089600"; d="scan'208";a="31425070" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Dec 2008 01:07:41 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBI17fZ8028835; Wed, 17 Dec 2008 20:07:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBI17emA021591; Thu, 18 Dec 2008 01:07:41 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 20:07:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 20:06:36 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C747@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <200812172217.mBHMH6PB030073@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclglT87nKVOMV94RTq402cfTHrxiwAFoApg References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com><26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com><8E296595B6471A4689555D5D725EBB2109F3C296@xmb-rtp-20a.amer.cisco.com> <200812172217.mBHMH6PB030073@cichlid.raleigh.ibm.com> From: "Bernie Volz (volz)" To: "Thomas Narten" X-OriginalArrivalTime: 18 Dec 2008 01:07:31.0175 (UTC) FILETIME=[008EFF70:01C960AD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3143; t=1229562461; x=1230426461; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Thomas=20Narten=22=20; bh=dL3yIbt/CUDbjiBJCpMSlLX0iMpq+uOLXqo1UNNw/rU=; b=J5GXC16I70HkileST+oQnEfBfIYOAEQF6qWxNakmwoOyG7/B83tqBCtlxo +chf560R+ceaEl3cOAzLkcUbGzKLltPCaYxakS6QQyT9z2dy1T6cRLArMnr+ vjF0Ds4ew/; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Dhcwg , Ted Lemon , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >> 2. Responses (from the server to relay) have stopped being sent because >> the server is not there. > >Well, this seems like a pretty narrow edge case. I.e., you just opened >a connection to the server, then before the server actually starting Perhaps you copied and pasted the wrong case, but that particular one is not such a narrow edge case. If there are 100K leases to be communicated, the server could "stop" sending at any time during those 100K leases. If the server crashed, how would the receiver know. (I don't know what the scale is likely to be for most cases, but having tens of thousands of DHCPv4 leases on a CMTS in Cable is not unrealistic today -- with IPv6 there's no reason not to expect the same level of scale once deployed.) >Anyway, a better way to deal with that is to (at the application >layer) add a specific "are you still there" ping/reply liveness test >(across TCP). You could do that at the application level pretty >easily. But it seems like overkill to me. Agreed; overkill. It also means that the server must be able to handle multiple requests from a client (the draft allows for the server to support this, but does not require it). I think for this case, waiting for a number of minutes should work reasonably well because not being able to send anything in several minutes is unlikely for a server and it addresses the ability for TCP to ride out short term connectivity issues (and for retransmissions to occur). And, again, this is likely to be used in environments where guarantees of service are much more likely -- and if they aren't met, there will be bigger issues than retrying TCP connections ever few minutes. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Wednesday, December 17, 2008 5:17 PM To: Bernie Volz (volz) Cc: Mark Stapp (mjs); IESG; Lars Eggert; Dhcwg; Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review > 2. Responses (from the server to relay) have stopped being sent because > the server is not there. Well, this seems like a pretty narrow edge case. I.e., you just opened a connection to the server, then before the server actually starting sending data, it crashes. This can happen with *ANY* protocol today. But it doesn't happen very often, and I can think of few protocols that actually worry about this case. I.e., we are talking of a window of a second or less, in most cases. Is it *really* that important to handle this case in your scenario? And how quickly would you need to detect this? (And the question of *how* would you respond to this event after detection is still unclear, IMO.) Anyway, a better way to deal with that is to (at the application layer) add a specific "are you still there" ping/reply liveness test (across TCP). You could do that at the application level pretty easily. But it seems like overkill to me. Thomas _______________________________________________ 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 dhcwg-bounces@ietf.org Wed Dec 17 20:55:41 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6159828C10C; Wed, 17 Dec 2008 20:55:41 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B4A28C10C for ; Wed, 17 Dec 2008 20:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4-nA+HgdBDL for ; Wed, 17 Dec 2008 20:55:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BAEFE3A6B5C for ; Wed, 17 Dec 2008 20:55:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,241,1228089600"; d="scan'208";a="215221359" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Dec 2008 04:55:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mBI4tV0w008537; Wed, 17 Dec 2008 20:55:31 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBI4tVC6022614; Thu, 18 Dec 2008 04:55:31 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 23:55:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 23:55:26 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20081217195129.GA6362@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt Thread-Index: AclggOnkPYg/T4isRmChbQGIsgD0/AASv+Dg References: <52AB41B5-F8FC-4EA7-BB13-2DAF91618715@cisco.com><8E296595B6471A4689555D5D725EBB2109F3C263@xmb-rtp-20a.amer.cisco.com> <20081217195129.GA6362@isc.org> From: "Bernie Volz (volz)" To: "David W. Hankins" , "DHC WG" X-OriginalArrivalTime: 18 Dec 2008 04:55:30.0837 (UTC) FILETIME=[DA45C450:01C960CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2568; t=1229576131; x=1230440131; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20*REMINDER*=3A=20dhc=20WG=20la st=20callon=09draft-ietf-dhc-vpn-option-09.txt |Sender:=20; bh=VqKG1h289OirNqfjExaLmaIK7qnW8jIeeoui/iQSFqI=; b=XhiQDH28rsLvWm5S7qE36DQmPbdkajVjfVzVEk8cA5GdFSvnTlzLh3HqeF qpIoZB16yHahGjUd7ur73GlRkNs7YhJ+Yu7HL0FnjPeB5nYRPYL2f/iI+kkC WFrtJi6WRA; Authentication-Results: sj-dkim-4; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I think ORO, if anything, is appropriate. ERO requests the option to be echoed back, which is different, as the VPN can change. I don't think the complexity of allow either ORO or ERO (and the subtle meaning difference) is worth it. Also, we have both the client and relay agent which could supply the option; ERO is only for relays, as clients are stateful and thus there's no reason they'd need something they sent in echoed. --- >This was an RFC 3942 action that intended standards track >instead of informational... Yes, the DHCPv4 option was that -- and there was no requirement for PRL. The DHCPv6 option is a bit different as it is new. And, we've been trying to be much better about using the ORO than we were the PRL. I don't have strong feelings either way. I lean towards considering this option a "core" protocol option and thus does not require ORO - if a server supports it, it must do processing to do so and hence there's really little need to include it in the ORO. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of David W. Hankins Sent: Wednesday, December 17, 2008 2:52 PM To: DHC WG Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt On Wed, Dec 17, 2008 at 12:48:03AM -0500, Bernie Volz (volz) wrote: > 2. For v6 (could also be an issue for v4), what happens if the > client/relay provides this option in the ORO (PRL)? And, should the > client/relay, if it wants it sent back, include it in the ORO (PRL)? > Perhaps we consider this a "core" protocol option (similar to the IA_NA, > IA_PD, IA_TA) where the option is not required to be in the ORO (PRL) as > the semantics require the server to send it back if received. ERO? I'm not sure if there are existing implementations we're working with either. This was an RFC 3942 action that intended standards track instead of informational... For DHCPv6 relay agents we have a curious situation as well. The relay agent's request option is the ERO; but this implies only echoing the relay's prior contents. Should the relay agent provide an ORO if it expects a VPN assignment, and ERO if it expects to assign the VPN? -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From johnblack@adamsmith.ac.uk Thu Dec 18 03:15:56 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F0C3A67C0 for ; Thu, 18 Dec 2008 03:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.292 X-Spam-Level: X-Spam-Status: No, score=-45.292 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlxVIcrEYy5i for ; Thu, 18 Dec 2008 03:15:55 -0800 (PST) Received: from aliecomix.com (unknown [201.37.109.191]) by core3.amsl.com (Postfix) with SMTP id 23B243A6919 for ; Thu, 18 Dec 2008 03:15:52 -0800 (PST) To: Subject: RE: Your inquiry From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081218111554.23B243A6919@core3.amsl.com> Date: Thu, 18 Dec 2008 03:15:52 -0800 (PST)
Go to site!
From dhcwg-bounces@ietf.org Thu Dec 18 08:43:19 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1C33A69F3; Thu, 18 Dec 2008 08:43:19 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938EC3A6AFB for ; Tue, 16 Dec 2008 23:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-1.959, BAYES_00=-2.599, FRT_STOCK2=3.988, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEvRaXJw2b+f for ; Tue, 16 Dec 2008 23:44:19 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 6F5DB3A68AC for ; Tue, 16 Dec 2008 23:44:18 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mBH7hXF5099350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2008 09:43:34 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> From: Lars Eggert To: Bernie Volz (volz) In-Reply-To: <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 09:43:32 +0200 References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com> <49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com> <49482D25.4080801@piuha.net> <8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 17 Dec 2008 09:43:35 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8770/Wed Dec 17 02:38:25 2008 on fit.nokia.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 18 Dec 2008 08:43:17 -0800 Cc: Thomas Narten , "Mark Stapp \(mjs\)" , IESG , Dhcwg , Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1150846250==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1150846250== Content-Type: multipart/signed; boundary=Apple-Mail-3--62973521; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-3--62973521 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: > Oh, no way! > > If the both ends enable keep-alives (some stacks do by default), the > there will be periodic probes but they generally don't time out for > minutes (I think for most BSD systems it works out to 9 or more if I > remember correctly). TCP keep-alives only kick in when there is no data to send in both directions, which isn't the case you're worried about. In your case, one end is trying to send data, but the throughput it is achieving isn't considered sufficient. The timeouts for failing to make send progress are usually on the order of minutes in typical stacks and often configurable via setsockopt. (For some more background information, see draft-ietf-tcpm-tcp-uto.) > And, if no keep-alives are sent, if the server crashes, the relay > may be > waiting forever. Not if it is trying to send data and not making progress. Lars PS: And yes, Thomas note pretty much matches my concerns with the document. > While everyone mentions non-fatal failures -- such as slow servers -- > there are lots of other conditions that could cause a significant > delay > in detecting a downed server or relay agent. > > These connections are mostly a one-way data flow - relay agent sends a > request, server sends lots of responses. > > TCP is great, don't get me wrong, but sometimes you need faster > response > than it offers. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, December 17, 2008 12:04 AM > To: Bernie Volz (volz) > Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; > IESG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > Why would a broken TCP connection stay up for 10 minutes? Shouldn't > it die within 90 seconds if no ACKs are forthcoming from the remote > end? --Apple-Mail-3--62973521 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODEyMTcwNzQzMzNaMCMGCSqGSIb3DQEJBDEWBBQUhRGuCKDE2b5q qlf92301PuM1BDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAQjkMQLWeDFc8f/AjUPI16aHXCfWevDCqE9Jl/WZqoS3QSwcoMayV FYt/fdU83/VHfrOUBoQS/mqxnbYHJmFVWg4pDvliMCAeMFXa1Owq59KbJDkVLbJrGh6ZYT5MLXgf d2jWdtftck0pe14Ag2gShLfMmDir7qmaq8yo/6naJrMGO+8F5lcVNmT/ebZK20RrA4GPZiXMoV/g PjMQ33d+WnZEcXzMZyQoThCluNoZ9gzKz3qZOPypqAtPUk4e1+9QEAFv186B7VZBg773PLtC4GM/ a6IioezCbZzPRbgmVdLHUHvSp5Ub58wyjfr9znJmkELNlbVF/7YwkhI2hAf48AAAAAAAAA== --Apple-Mail-3--62973521-- --===============1150846250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1150846250==-- From dhcwg-bounces@ietf.org Thu Dec 18 08:48:07 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDC928C0FB; Thu, 18 Dec 2008 08:48:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEE03A6B8C; Thu, 18 Dec 2008 08:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.451 X-Spam-Level: X-Spam-Status: No, score=-4.451 tagged_above=-999 required=5 tests=[AWL=-1.840, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umwjDvLSldfC; Thu, 18 Dec 2008 08:48:05 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D07843A6A01; Thu, 18 Dec 2008 08:48:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,243,1228089600"; d="scan'208";a="31493459" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Dec 2008 16:47:56 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBIGluPU028065; Thu, 18 Dec 2008 11:47:56 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBIGluGC025460; Thu, 18 Dec 2008 16:47:56 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 11:47:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 11:47:15 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210A029D2A@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: AclhL7zy0phtq1Z4RRGdDVHPpy5vzwAACnyQ References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> From: "Bernie Volz (volz)" To: "Lars Eggert" X-OriginalArrivalTime: 18 Dec 2008 16:47:56.0638 (UTC) FILETIME=[60C15FE0:01C96130] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2835; t=1229618876; x=1230482876; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Lars=20Eggert=22=20; bh=MN+ndjYsgONbpVIVfBZTwtlyryeYDjkkpI8FA7W2e+E=; b=LfOlZYrpS7l8HnU2XYdQnZ4Cld6JhjxUKmYlFEoO2FSpI8I1EK3abLPcJI rJYPR2ctCMrSdyMs2bEtGJCPtGZGFfqh6jykMsFodsoFvSNQPmkjC+ZraRXA GqQEPrE/F1; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Thomas Narten , Dhcwg , Ted Lemon , "Mark Stapp \(mjs\)" , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Lars: One of the events I'm worried about is when the server system becomes unreachable and thus no data is flowing. The other case is when the server is waiting for the first or "next" request after having completed one - such as when the relay agent becomes unreachable either after opening the connection or after having received all of the data. In neither of these cases is data flowing. Hence, keep-alives are required or an application timeout to handle the case when no data is received over some period of time. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Wednesday, December 17, 2008 2:44 AM To: Bernie Volz (volz) Cc: Thomas Narten; Mark Stapp (mjs); IESG; Dhcwg; Ted Lemon Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: > Oh, no way! > > If the both ends enable keep-alives (some stacks do by default), the > there will be periodic probes but they generally don't time out for > minutes (I think for most BSD systems it works out to 9 or more if I > remember correctly). TCP keep-alives only kick in when there is no data to send in both directions, which isn't the case you're worried about. In your case, one end is trying to send data, but the throughput it is achieving isn't considered sufficient. The timeouts for failing to make send progress are usually on the order of minutes in typical stacks and often configurable via setsockopt. (For some more background information, see draft-ietf-tcpm-tcp-uto.) > And, if no keep-alives are sent, if the server crashes, the relay > may be > waiting forever. Not if it is trying to send data and not making progress. Lars PS: And yes, Thomas note pretty much matches my concerns with the document. > While everyone mentions non-fatal failures -- such as slow servers -- > there are lots of other conditions that could cause a significant > delay > in detecting a downed server or relay agent. > > These connections are mostly a one-way data flow - relay agent sends a > request, server sends lots of responses. > > TCP is great, don't get me wrong, but sometimes you need faster > response > than it offers. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, December 17, 2008 12:04 AM > To: Bernie Volz (volz) > Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; > IESG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > Why would a broken TCP connection stay up for 10 minutes? Shouldn't > it die within 90 seconds if no ACKs are forthcoming from the remote > end? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Dec 18 09:51:29 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659743A68D8; Thu, 18 Dec 2008 09:51:29 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC093A68D8 for ; Thu, 18 Dec 2008 09:51:28 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQchAD-OPTl5 for ; Thu, 18 Dec 2008 09:51:27 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id C969D3A679C for ; Thu, 18 Dec 2008 09:51:27 -0800 (PST) Received: from hcf.isc.org (dhcp-194.sql1.isc.org [204.152.187.194]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBIHpKVF010704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Dec 2008 09:51:20 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 2E6E55732E; Thu, 18 Dec 2008 09:52:33 -0800 (PST) Date: Thu, 18 Dec 2008 09:52:33 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081218175232.GA3310@isc.org> References: <20081217195129.GA6362@isc.org> <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB2109F3C79A@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0792075247==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0792075247== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 17, 2008 at 11:55:26PM -0500, Bernie Volz (volz) wrote: > I think ORO, if anything, is appropriate. ERO requests the option to be > echoed back, which is different, as the VPN can change. I don't think > the complexity of allow either ORO or ERO (and the subtle meaning > difference) is worth it. >=20 > Also, we have both the client and relay agent which could supply the > option; ERO is only for relays, as clients are stateful and thus there's > no reason they'd need something they sent in echoed. Yes; but the draft describes several different scenarios, some of which the relay would expect its transmitted value returned, and in others would expect an assignment by the server. > I don't have strong feelings either way. I lean towards considering this > option a "core" protocol option and thus does not require ORO - if a > server supports it, it must do processing to do so and hence there's > really little need to include it in the ORO. I don't think processing is required in all of the scenarios the draft supposes. So I'd lean towards putting the option on ORO; older servers with no support can still mimic sufficient support with manually or scripted values, but they won't send the value unless it's on ORO. This also simplifies DHCPv6 packet creation routines by treating more options consistently the same. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklKjeAACgkQcXeLeWu2vmoaHwCfSXStGvDzLi7MexssDoFsAw4e MTQAn1lzTFSrMma5kDjTm2ZS9PR9Yk0J =C8Ec -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- --===============0792075247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============0792075247==-- From dhcwg-bounces@ietf.org Thu Dec 18 14:29:40 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEA428C10E; Thu, 18 Dec 2008 14:29:40 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3627928C108 for ; Thu, 18 Dec 2008 14:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppMpT+7-WyMa for ; Thu, 18 Dec 2008 14:29:38 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1B42C28C104 for ; Thu, 18 Dec 2008 14:29:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,245,1228089600"; d="scan'208";a="31501798" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2008 22:29:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBIMTUmc027503 for ; Thu, 18 Dec 2008 17:29:30 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBIMTU0s022340 for ; Thu, 18 Dec 2008 22:29:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 17:29:29 -0500 Received: from [10.86.251.119] ([10.86.251.119]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 17:29:29 -0500 Message-ID: <494ACECA.4080606@cisco.com> Date: Thu, 18 Dec 2008 17:29:30 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Kim Kinnear References: <4.3.2.7.2.20081217165359.0378bb40@email.cisco.com> In-Reply-To: <4.3.2.7.2.20081217165359.0378bb40@email.cisco.com> X-OriginalArrivalTime: 18 Dec 2008 22:29:29.0582 (UTC) FILETIME=[178078E0:01C96160] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2005; t=1229639370; x=1230503370; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20REMINDER=3A=20dhc=20WG=20last =20call=20on=20draft-ietf-dhc-relay-id-suboption-04.txt |Sender:=20 |To:=20Kim=20Kinnear=20; bh=jrIJeeEGO5xO4u14JyY4Zqmm9ntjEetQ5+EA2ZD3uv8=; b=P6d7ONn48/EnMTW056bvBcCjEo6PDyM6cAQfyMDcDa9oUa874/p7nH6oE5 8Pzh094UyjnYOJtWslzCJx040575rW9L4gi6OCponVfOVBsd9dS9IsIUXvPC j9ZYKPWA1n; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dhc WG Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay-id-suboption-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Kim, thanks for the great comments. I'm posting an updated version of the draft. Kim Kinnear wrote: > 1. In section 3.2, Bulk Leasequery, the world has moved on since > these words were written. [...] > done - converged to the one-true-draft. > 2. In section 5, Relay Identifier Types, it would be useful to > simply include a table with the defined numeric values for > RELAY_IDENTIFIER_DUID and RELAY_IDENTIFIER_ASCII. IANA isn't > going to change these values, and it seems difficult (and > unusual) to send the implementor off to the IANA section to find > the actual values of these constants. > Ah - I've actually gotten pushed the other way recently about the handling of IANA values. The current 'best practice' seems to be to keep all the actual number assignments in one place - in the IANA section - and to use tokens elsewhere in the document. Unless you feel it's really confusing, I'd like to leave the IANA material as-is: I'm afraid I'd just have to change it back during IESG review. > 3. In section 7, Identifier Stability, it might be useful to > discuss something about Identifier Continuity in the context of > stability. You have used the Industrial Ethernet as a use case > (which I think was a good idea), and one of the difficulties of > this particular use case is what to do when a relay agent has to > be replaced. This would seem to be the place to specify some > behavior as to how to handle one device taking over for a failed > device. It would seem to me that allowing (or requiring) devices > to be able to generate a DUID that matches that of a previous > plug-compatible (or at least port-compatible) device might be > useful here. > Yes, thanks - that's a very good point. I've added another paragraph to that section to describe the situation where a relay device is replaced, and explain that this is a reason for implementors to permit admin configuration of the identifier value. Thanks, Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Dec 18 15:00:02 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C951F3A6958; Thu, 18 Dec 2008 15:00:02 -0800 (PST) X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 540363A6958; Thu, 18 Dec 2008 15:00:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081218230001.540363A6958@core3.amsl.com> Date: Thu, 18 Dec 2008 15:00:01 -0800 (PST) Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-relay-id-suboption-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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) : M. Stapp Filename : draft-ietf-dhc-relay-id-suboption-06.txt Pages : 7 Date : 2008-12-18 This memo 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. The value may be administratively-configured or may be generated by 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18145434.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Dec 19 06:38:05 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD873A6948; Fri, 19 Dec 2008 06:38:05 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9144E3A6948; Fri, 19 Dec 2008 06:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.232 X-Spam-Level: * X-Spam-Status: No, score=1.232 tagged_above=-999 required=5 tests=[AWL=-1.621, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noh-wfoErMJA; Fri, 19 Dec 2008 06:38:02 -0800 (PST) Received: from mail.fit.nokia.com (host-39.nrln.net [212.213.221.39]) by core3.amsl.com (Postfix) with ESMTP id 18ACB3A68BF; Fri, 19 Dec 2008 06:38:01 -0800 (PST) Received: from [192.168.255.2] (a88-112-30-134.elisa-laajakaista.fi [88.112.30.134]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mBJEbLYN047653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2008 16:37:23 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Bernie Volz (volz) In-Reply-To: <8E296595B6471A4689555D5D725EBB210A029D2A@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 19 Dec 2008 16:37:21 +0200 References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com> <26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com> <8E296595B6471A4689555D5D725EBB210A029D2A@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Fri, 19 Dec 2008 16:37:23 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8786/Fri Dec 19 12:30:31 2008 on fit.nokia.com X-Virus-Status: Clean Cc: Thomas Narten , Dhcwg , Ted Lemon , "Mark Stapp \(mjs\)" , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1683404215==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1683404215== Content-Type: multipart/signed; boundary=Apple-Mail-24-134655089; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-24-134655089 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2008-12-18, at 18:47, Bernie Volz (volz) wrote: > One of the events I'm worried about is when the server system becomes > unreachable and thus no data is flowing. there are two cases here: Case 1: the connection is idle, i.e., neither end has data queued for transmission in the socket buffers. This is the case where TCP keepalives help. They let you detect that the other end has disappeared, which without keepalives you'd only notice when you'd try to send to or receive from the other end. Question: if your end isn't trying to send to or receive from the other end, is there any use in tearing down the connection via a keealive? Case 2: the connection is not idle, i.e., at least one end has data queued for transmission in its socket buffer. TCP keepalives aren'a a factor here - the TCP stack on the sending side will tear down the connection after a few sending attempts fail to generate ACKs. On typical stacks, this happens after a few minutes. Is there any need for an additional mechanism in either of these two cases? Lars > The other case is when the server is waiting for the first or "next" > request after having completed one - such as when the relay agent > becomes unreachable either after opening the connection or after > having > received all of the data. > > In neither of these cases is data flowing. Hence, keep-alives are > required or an application timeout to handle the case when no data is > received over some period of time. > > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: Wednesday, December 17, 2008 2:44 AM > To: Bernie Volz (volz) > Cc: Thomas Narten; Mark Stapp (mjs); IESG; Dhcwg; Ted Lemon > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: >> Oh, no way! >> >> If the both ends enable keep-alives (some stacks do by default), the >> there will be periodic probes but they generally don't time out for >> minutes (I think for most BSD systems it works out to 9 or more if I >> remember correctly). > > TCP keep-alives only kick in when there is no data to send in both > directions, which isn't the case you're worried about. In your case, > one end is trying to send data, but the throughput it is achieving > isn't considered sufficient. The timeouts for failing to make send > progress are usually on the order of minutes in typical stacks and > often configurable via setsockopt. (For some more background > information, see draft-ietf-tcpm-tcp-uto.) > >> And, if no keep-alives are sent, if the server crashes, the relay >> may be >> waiting forever. > > Not if it is trying to send data and not making progress. > > Lars > > PS: And yes, Thomas note pretty much matches my concerns with the > document. > >> While everyone mentions non-fatal failures -- such as slow servers -- >> there are lots of other conditions that could cause a significant >> delay >> in detecting a downed server or relay agent. >> >> These connections are mostly a one-way data flow - relay agent >> sends a >> request, server sends lots of responses. >> >> TCP is great, don't get me wrong, but sometimes you need faster >> response >> than it offers. >> >> - Bernie >> >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: Wednesday, December 17, 2008 12:04 AM >> To: Bernie Volz (volz) >> Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; >> IESG >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG >> review >> >> Why would a broken TCP connection stay up for 10 minutes? Shouldn't >> it die within 90 seconds if no ACKs are forthcoming from the remote >> end? --Apple-Mail-24-134655089 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODEyMTkxNDM3MjJaMCMGCSqGSIb3DQEJBDEWBBQvi5NZXyN9bf15 d5wLoFQC9GMbGzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAATX1+Be7TgINsgLiXcIaGMsQihvQTstHPepZyK59X+MOX7CjOMMb Ga4XUjcggWaX4O2y9QyAe9k3KQJyGBxYeuhsbgFlOjcVwXhNwTdGn9GVNUw4HihhbP7iT87j4uyl lCSPDPS1DgDyV/qLbKsiYBdH9K+3X8UXGbySs9gMgaqvtM0Jdht3NyBIEL0xvGT8Pg0DGl3MBhZn P/cvY2PeDHdKo3zXZfObhL7M8m3/7YrW/VQOVS/kZaPaFv7WDqim3zHtd/H/9GPGIytuOFX5Rh38 tdkTPXvcp7lsdOl1tTWEPoOm/FOoraE5F7RTUWvXE3kWrrAIzQ1vAbHt1weAOQAAAAAAAA== --Apple-Mail-24-134655089-- --===============1683404215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1683404215==-- From dhcwg-bounces@ietf.org Fri Dec 19 07:26:01 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3633A69F9; Fri, 19 Dec 2008 07:26:01 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DB73A69F9; Fri, 19 Dec 2008 07:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.071 X-Spam-Level: X-Spam-Status: No, score=-4.071 tagged_above=-999 required=5 tests=[AWL=-2.060, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6X8J5CL-H2v; Fri, 19 Dec 2008 07:25:58 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D38043A6968; Fri, 19 Dec 2008 07:25:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,249,1228089600"; d="scan'208";a="31554854" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Dec 2008 15:25:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBJFPaLb024457; Fri, 19 Dec 2008 10:25:36 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJFPasV003761; Fri, 19 Dec 2008 15:25:36 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 10:25:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 10:25:20 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210A02A104@xmb-rtp-20a.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: Aclh53XWNv6dEByATEymhdEZawvPiQABADpw References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com><26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com><8E296595B6471A4689555D5D725EBB210A029D2A@xmb-rtp-20a.amer.cisco.com> From: "Bernie Volz (volz)" To: "Lars Eggert" X-OriginalArrivalTime: 19 Dec 2008 15:25:36.0119 (UTC) FILETIME=[0A63C070:01C961EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7707; t=1229700336; x=1230564336; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Lars=20Eggert=22=20; bh=uWxoaMFQgpt7l5nWWXjnWqq0xMoAk0acX1CKJJkAs+M=; b=YyAYEp20SpDy4BURv/AB1PAhOKFSTq5jPqxatwwpFlfw5ye87MZ+YuREHb Hs0VjUA6Zm8KiKyrc0lYU3RLPjhIvAyhh/GTsDHhZqOQsbkXVOsgDbQfWE6h djbuFwDpsY; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Thomas Narten , Dhcwg , IESG , Ted Lemon , "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org For case 1, keepalives help but the application is left to the stack to eventually signal the timeout. An application should NOT be required to rely solely on that -- an application should be able to shut down the connection earlier if it feels it isn't making sufficient progress. Also, keepalives may not always be available (?) or there are other issues that prevent keepalives from being completely effective. And, the connection may be idle because it just is - neither side has any data to send. Thus, again, a server (or client) should be able to close the connection. FTP does this. I think none of these cases are a problem *IF* the "timeout" is reasonable. For case 2, there are two causes - one is that the receiver isn't reading data from the socket and hence the sender is blocked from sending more data; the other is that the receiver is no longer there (or is unreachable for an extended period). The first would "never" abort the connection unless the one end takes some action. The second will eventually result in the connection being shut down (but note that in this case, the sender detects this but the receiver end may not -- that depends on your case 1. Again, an application should be able to have its own time out as long as it is reasonable. In any case, it is NOT appropriate to rely ONLY on TCP to provide these signals. Clients and servers that do will sometimes end up waiting for action for long periods of time (something usually gives in the end but it could be days, weeks, or months and is often the result of some operator or 'external' (ie loss of power) action). If an application timeout does not exist, the cost is consuming some system (and application) resources. It may not be high for each connection, but if one were to have a bug in a relay agent software release that causes it to stop reading and one were to have 100s of those relays ... I think you get the point. This is NOT new. FTP servers and other applications have had application level timeouts. I think the orignal concerns were what we need to go back to: A) The timeout times were very short; they need to be longer to allow TCP to "do its thing". B) The recovery techniques, especially if the timeouts were short, were flawed because they recommended to retry the connection/operation. If the timeout were 10 minutes and the recovery was as stated, I don't think this would be that big an issue because trying once every 10 minutes is not a major concern. RFC 1123 states: 4.1.3.2 Idle Timeout A Server-FTP process SHOULD have an idle timeout, which will terminate the process and close the control connection if the server is inactive (i.e., no command or data transfer in progress) for a long period of time. The idle timeout time SHOULD be configurable, and the default should be at least 5 minutes. A client FTP process ("User-PI" in RFC-959) will need timeouts on responses only if it is invoked from a program. DISCUSSION: Without a timeout, a Server-FTP process may be left pending indefinitely if the corresponding client crashes without closing the control connection. So, if the draft had specified a BULK_LQ_DATA_TIMEOUT of 5 minutes, we would NOT be having this discussion, would we? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Friday, December 19, 2008 9:37 AM To: Bernie Volz (volz) Cc: Thomas Narten; Dhcwg; Ted Lemon; Mark Stapp (mjs); IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Hi, On 2008-12-18, at 18:47, Bernie Volz (volz) wrote: > One of the events I'm worried about is when the server system becomes > unreachable and thus no data is flowing. there are two cases here: Case 1: the connection is idle, i.e., neither end has data queued for transmission in the socket buffers. This is the case where TCP keepalives help. They let you detect that the other end has disappeared, which without keepalives you'd only notice when you'd try to send to or receive from the other end. Question: if your end isn't trying to send to or receive from the other end, is there any use in tearing down the connection via a keealive? Case 2: the connection is not idle, i.e., at least one end has data queued for transmission in its socket buffer. TCP keepalives aren'a a factor here - the TCP stack on the sending side will tear down the connection after a few sending attempts fail to generate ACKs. On typical stacks, this happens after a few minutes. Is there any need for an additional mechanism in either of these two cases? Lars > The other case is when the server is waiting for the first or "next" > request after having completed one - such as when the relay agent > becomes unreachable either after opening the connection or after > having > received all of the data. > > In neither of these cases is data flowing. Hence, keep-alives are > required or an application timeout to handle the case when no data is > received over some period of time. > > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: Wednesday, December 17, 2008 2:44 AM > To: Bernie Volz (volz) > Cc: Thomas Narten; Mark Stapp (mjs); IESG; Dhcwg; Ted Lemon > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: >> Oh, no way! >> >> If the both ends enable keep-alives (some stacks do by default), the >> there will be periodic probes but they generally don't time out for >> minutes (I think for most BSD systems it works out to 9 or more if I >> remember correctly). > > TCP keep-alives only kick in when there is no data to send in both > directions, which isn't the case you're worried about. In your case, > one end is trying to send data, but the throughput it is achieving > isn't considered sufficient. The timeouts for failing to make send > progress are usually on the order of minutes in typical stacks and > often configurable via setsockopt. (For some more background > information, see draft-ietf-tcpm-tcp-uto.) > >> And, if no keep-alives are sent, if the server crashes, the relay >> may be >> waiting forever. > > Not if it is trying to send data and not making progress. > > Lars > > PS: And yes, Thomas note pretty much matches my concerns with the > document. > >> While everyone mentions non-fatal failures -- such as slow servers -- >> there are lots of other conditions that could cause a significant >> delay >> in detecting a downed server or relay agent. >> >> These connections are mostly a one-way data flow - relay agent >> sends a >> request, server sends lots of responses. >> >> TCP is great, don't get me wrong, but sometimes you need faster >> response >> than it offers. >> >> - Bernie >> >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: Wednesday, December 17, 2008 12:04 AM >> To: Bernie Volz (volz) >> Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; >> IESG >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG >> review >> >> Why would a broken TCP connection stay up for 10 minutes? Shouldn't >> it die within 90 seconds if no ACKs are forthcoming from the remote >> end? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 19 07:42:10 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E645928C122; Fri, 19 Dec 2008 07:42:10 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED2428C101; Fri, 19 Dec 2008 07:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfnMKbUCJIsY; Fri, 19 Dec 2008 07:42:08 -0800 (PST) Received: from mail.fit.nokia.com (host-39.nrln.net [212.213.221.39]) by core3.amsl.com (Postfix) with ESMTP id C69F828C102; Fri, 19 Dec 2008 07:42:07 -0800 (PST) Received: from [192.168.255.2] (a88-112-30-134.elisa-laajakaista.fi [88.112.30.134]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mBJFffai048357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2008 17:41:41 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <5CD63C4E-E984-4A3C-BF9D-AEBA9E04F3A4@nokia.com> From: Lars Eggert To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB210A02A104@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 19 Dec 2008 17:41:40 +0200 References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com><26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com><8E296595B6471A4689555D5D725EBB210A029D2A@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB210A02A104@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Fri, 19 Dec 2008 17:41:43 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8786/Fri Dec 19 12:30:31 2008 on fit.nokia.com X-Virus-Status: Clean Cc: Thomas Narten , Dhcwg , IESG , Ted Lemon , "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1863512720==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1863512720== Content-Type: multipart/signed; boundary=Apple-Mail-35-138514353; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-35-138514353 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2008-12-19, at 17:25, Bernie Volz (volz) wrote: > For case 1, keepalives help but the application is left to the stack > to > eventually signal the timeout. An application should NOT be required > to > rely solely on that -- an application should be able to shut down the > connection earlier if it feels it isn't making sufficient progress. I agree that an application is free to stop a connection when it feels that it doesn't make sufficient progress, and assuming that mechanism are in place to establish some quiet time after that has happened. But I'm confused to hear you talk about "progress" here. Case 1 is when neither end has any data to send - there isn't anything on which to make progress on. Which is why I'm wondering why it is considered important to tear such connections down. > Also, keepalives may not always be available (?) or there are other > issues that prevent keepalives from being completely effective. And, > the > connection may be idle because it just is - neither side has any > data to > send. Thus, again, a server (or client) should be able to close the > connection. FTP does this. Generally agreed, but not in case 1. > I think none of these cases are a problem *IF* the "timeout" is > reasonable. Yup. > For case 2, there are two causes - one is that the receiver isn't > reading data from the socket and hence the sender is blocked from > sending more data; the other is that the receiver is no longer there > (or > is unreachable for an extended period). The first would "never" abort > the connection unless the one end takes some action. The second will > eventually result in the connection being shut down (but note that in > this case, the sender detects this but the receiver end may not -- > that > depends on your case 1. > > Again, an application should be able to have its own time out as > long as > it is reasonable. I agree - my discuss position isn't saying that you shouldn't do this, it's saying that the current description of the timeout scheme isn't sufficiently well described. It contains statements like "is blocked", "makes progress", etc. that simply aren't visible via the sockets API. Even when that's changed to talk about having been able to send or receive within some amount of time, the only thing the application knows is that the socket API call returned, which esp. for sending does NOT correspond to progress happening at the connection level, at least for short sends. > In any case, it is NOT appropriate to rely ONLY on TCP to provide > these > signals. Clients and servers that do will sometimes end up waiting for > action for long periods of time (something usually gives in the end > but > it could be days, weeks, or months and is often the result of some > operator or 'external' (ie loss of power) action). > > If an application timeout does not exist, the cost is consuming some > system (and application) resources. It may not be high for each > connection, but if one were to have a bug in a relay agent software > release that causes it to stop reading and one were to have 100s of > those relays ... I think you get the point. > > This is NOT new. FTP servers and other applications have had > application > level timeouts. I think the orignal concerns were what we need to go > back to: > A) The timeout times were very short; they need to be longer to allow > TCP to "do its thing". > B) The recovery techniques, especially if the timeouts were short, > were > flawed because they recommended to retry the connection/operation. If > the timeout were 10 minutes and the recovery was as stated, I don't > think this would be that big an issue because trying once every 10 > minutes is not a major concern. Yes. And the description of the timeout scheme needs to be written in a way that's actually implementable based on the information that the TCP API provides to the application. > RFC 1123 states: > > 4.1.3.2 Idle Timeout > > A Server-FTP process SHOULD have an idle timeout, which > will > terminate the process and close the control connection if > the server is inactive (i.e., no command or data transfer > in > progress) for a long period of time. The idle timeout time > SHOULD be configurable, and the default should be at > least 5 > minutes. > > A client FTP process ("User-PI" in RFC-959) will need > timeouts on responses only if it is invoked from a program. > > DISCUSSION: > Without a timeout, a Server-FTP process may be left > pending indefinitely if the corresponding client > crashes without closing the control connection. > > So, if the draft had specified a BULK_LQ_DATA_TIMEOUT of 5 minutes, we > would NOT be having this discussion, would we? We wouldn't have the part of the discussion about the length of the timeouts. We would still be having the discussion about the clarity of the description of the proposed timeout scheme. Lars > > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: Friday, December 19, 2008 9:37 AM > To: Bernie Volz (volz) > Cc: Thomas Narten; Dhcwg; Ted Lemon; Mark Stapp (mjs); IESG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > Hi, > > On 2008-12-18, at 18:47, Bernie Volz (volz) wrote: >> One of the events I'm worried about is when the server system becomes >> unreachable and thus no data is flowing. > > there are two cases here: > > Case 1: the connection is idle, i.e., neither end has data queued for > transmission in the socket buffers. This is the case where TCP > keepalives help. They let you detect that the other end has > disappeared, which without keepalives you'd only notice when you'd try > to send to or receive from the other end. Question: if your end isn't > trying to send to or receive from the other end, is there any use in > tearing down the connection via a keealive? > > Case 2: the connection is not idle, i.e., at least one end has data > queued for transmission in its socket buffer. TCP keepalives aren'a a > factor here - the TCP stack on the sending side will tear down the > connection after a few sending attempts fail to generate ACKs. On > typical stacks, this happens after a few minutes. > > Is there any need for an additional mechanism in either of these two > cases? > > Lars > >> The other case is when the server is waiting for the first or "next" >> request after having completed one - such as when the relay agent >> becomes unreachable either after opening the connection or after >> having >> received all of the data. >> >> In neither of these cases is data flowing. Hence, keep-alives are >> required or an application timeout to handle the case when no data is >> received over some period of time. > > > >> >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf >> Of Lars Eggert >> Sent: Wednesday, December 17, 2008 2:44 AM >> To: Bernie Volz (volz) >> Cc: Thomas Narten; Mark Stapp (mjs); IESG; Dhcwg; Ted Lemon >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG >> review >> >> On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: >>> Oh, no way! >>> >>> If the both ends enable keep-alives (some stacks do by default), the >>> there will be periodic probes but they generally don't time out for >>> minutes (I think for most BSD systems it works out to 9 or more if I >>> remember correctly). >> >> TCP keep-alives only kick in when there is no data to send in both >> directions, which isn't the case you're worried about. In your case, >> one end is trying to send data, but the throughput it is achieving >> isn't considered sufficient. The timeouts for failing to make send >> progress are usually on the order of minutes in typical stacks and >> often configurable via setsockopt. (For some more background >> information, see draft-ietf-tcpm-tcp-uto.) >> >>> And, if no keep-alives are sent, if the server crashes, the relay >>> may be >>> waiting forever. >> >> Not if it is trying to send data and not making progress. >> >> Lars >> >> PS: And yes, Thomas note pretty much matches my concerns with the >> document. >> >>> While everyone mentions non-fatal failures -- such as slow servers >>> -- >>> there are lots of other conditions that could cause a significant >>> delay >>> in detecting a downed server or relay agent. >>> >>> These connections are mostly a one-way data flow - relay agent >>> sends a >>> request, server sends lots of responses. >>> >>> TCP is great, don't get me wrong, but sometimes you need faster >>> response >>> than it offers. >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >>> Sent: Wednesday, December 17, 2008 12:04 AM >>> To: Bernie Volz (volz) >>> Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; >>> IESG >>> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG >>> review >>> >>> Why would a broken TCP connection stay up for 10 minutes? >>> Shouldn't >>> it die within 90 seconds if no ACKs are forthcoming from the remote >>> end? --Apple-Mail-35-138514353 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODEyMTkxNTQxNDFaMCMGCSqGSIb3DQEJBDEWBBR3J+O7Hh0HcBuK EUsCBSk9VpRxmzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAMnnV7r708KIZ7NWQ/hJlAgOs7MjshvRHgF6z1Fg8M2Y1wXFEBYDa 6wrOB2r3p6QVtgnbeib7Q8J7lBTjqRiwL7sEBSR7WVEjd8uBTJRjVpeWYXEjr8Tf+7AMGPwvLOCp SeR+14rZpQOJ3QuutuGpeO7wR5efuvZXUywaSr7svADZ2v+vXW84kqC296Sv/5l/MOWouu0MgfK6 xoHT/0nAqCVECQ1/AOG8m0SzPzXN4gDfSV7XfxMohjXRmLWHSx1f7NP1rzsHxbsXuN0XyNpR6JWT woaIcE3iBi2xFlI1ziiSrIEX6cmgfHi7ymtOJAIt6wLCY7jtVFGqoHK3QOSQngAAAAAAAA== --Apple-Mail-35-138514353-- --===============1863512720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1863512720==-- From dhcwg-bounces@ietf.org Fri Dec 19 07:54:07 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991AD28C125; Fri, 19 Dec 2008 07:54:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67C23A69F6; Fri, 19 Dec 2008 07:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.985 X-Spam-Level: X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[AWL=-1.974, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAM904UIeAua; Fri, 19 Dec 2008 07:54:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 382333A6819; Fri, 19 Dec 2008 07:54:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,249,1228089600"; d="scan'208";a="31596149" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Dec 2008 15:53:56 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBJFrurv019774; Fri, 19 Dec 2008 10:53:56 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJFrrWG014755; Fri, 19 Dec 2008 15:53:56 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 10:53:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 10:53:26 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210A02A148@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <5CD63C4E-E984-4A3C-BF9D-AEBA9E04F3A4@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: Aclh8FUgmimDeZqnR6+ZK/Ql0pjEQQAAHlrA References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><8E296595B6471A4689555D5D725EBB2109F3C262@xmb-rtp-20a.amer.cisco.com><26B14C4F-37CF-43A1-AAAD-13E64223DE12@nokia.com><8E296595B6471A4689555D5D725EBB210A029D2A@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB210A02A104@xmb-rtp-20a.amer.cisco.com> <5CD63C4E-E984-4A3C-BF9D-AEBA9E04F3A4@nokia.com> From: "Bernie Volz (volz)" To: "Lars Eggert" X-OriginalArrivalTime: 19 Dec 2008 15:53:55.0442 (UTC) FILETIME=[FF43DD20:01C961F1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11148; t=1229702036; x=1230566036; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Lars=20Eggert=22=20; bh=fgUPWgHj2jGAF9PMu10tmAvjA+jLTJB7T1OHR16/e6o=; b=BHqREziQwZ6jpy+CV2lRmwq+s6t6m4PkI1cFjSmVMIgP7upE1XMKJPLj7s R9HWOgasoGHOPQZw5CHuL4qiAuKpy7KzMOpv9wud0OwKsQKaahPdc7OdYEyu 63+Gvyhp0q; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Thomas Narten , Dhcwg , IESG , Ted Lemon , "Mark Stapp \(mjs\)" Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >But I'm confused to hear you talk about "progress" here. Case 1 is >when neither end has any data to send - there isn't anything on which >to make progress on. Which is why I'm wondering why it is considered >important to tear such connections down. Huh? This is exactly what the FTP idle timeout text in RFC 1123 was all about! --- >It contains statements like "is blocked", "makes progress", etc. that >simply aren't visible via the sockets API. Even when that's changed to "progress" and "blocked" are VISIBLE from the socket API. Progress means that you're able to issue additional send() or recv() calls and get them completed (before whatever timeout, if any). Blocked means that you aren't. If the socket is set to non-blocking mode, EWOULDBLOCK would be returned. You can easily write code to do this by using select to limit how long you wait to send or receive (you don't need to use non-blocking sockets). Before reading, select on the socket being readable with a timeout. Before sending, select on the socket being writeable with a timeout (though in this case, there is a risk of blocking on the send if the socket is non-blocking). - Bernie -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Friday, December 19, 2008 10:42 AM To: Bernie Volz (volz) Cc: Thomas Narten; Dhcwg; Ted Lemon; Mark Stapp (mjs); IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Hi, On 2008-12-19, at 17:25, Bernie Volz (volz) wrote: > For case 1, keepalives help but the application is left to the stack > to > eventually signal the timeout. An application should NOT be required > to > rely solely on that -- an application should be able to shut down the > connection earlier if it feels it isn't making sufficient progress. I agree that an application is free to stop a connection when it feels that it doesn't make sufficient progress, and assuming that mechanism are in place to establish some quiet time after that has happened. But I'm confused to hear you talk about "progress" here. Case 1 is when neither end has any data to send - there isn't anything on which to make progress on. Which is why I'm wondering why it is considered important to tear such connections down. > Also, keepalives may not always be available (?) or there are other > issues that prevent keepalives from being completely effective. And, > the > connection may be idle because it just is - neither side has any > data to > send. Thus, again, a server (or client) should be able to close the > connection. FTP does this. Generally agreed, but not in case 1. > I think none of these cases are a problem *IF* the "timeout" is > reasonable. Yup. > For case 2, there are two causes - one is that the receiver isn't > reading data from the socket and hence the sender is blocked from > sending more data; the other is that the receiver is no longer there > (or > is unreachable for an extended period). The first would "never" abort > the connection unless the one end takes some action. The second will > eventually result in the connection being shut down (but note that in > this case, the sender detects this but the receiver end may not -- > that > depends on your case 1. > > Again, an application should be able to have its own time out as > long as > it is reasonable. I agree - my discuss position isn't saying that you shouldn't do this, it's saying that the current description of the timeout scheme isn't sufficiently well described. It contains statements like "is blocked", "makes progress", etc. that simply aren't visible via the sockets API. Even when that's changed to talk about having been able to send or receive within some amount of time, the only thing the application knows is that the socket API call returned, which esp. for sending does NOT correspond to progress happening at the connection level, at least for short sends. > In any case, it is NOT appropriate to rely ONLY on TCP to provide > these > signals. Clients and servers that do will sometimes end up waiting for > action for long periods of time (something usually gives in the end > but > it could be days, weeks, or months and is often the result of some > operator or 'external' (ie loss of power) action). > > If an application timeout does not exist, the cost is consuming some > system (and application) resources. It may not be high for each > connection, but if one were to have a bug in a relay agent software > release that causes it to stop reading and one were to have 100s of > those relays ... I think you get the point. > > This is NOT new. FTP servers and other applications have had > application > level timeouts. I think the orignal concerns were what we need to go > back to: > A) The timeout times were very short; they need to be longer to allow > TCP to "do its thing". > B) The recovery techniques, especially if the timeouts were short, > were > flawed because they recommended to retry the connection/operation. If > the timeout were 10 minutes and the recovery was as stated, I don't > think this would be that big an issue because trying once every 10 > minutes is not a major concern. Yes. And the description of the timeout scheme needs to be written in a way that's actually implementable based on the information that the TCP API provides to the application. > RFC 1123 states: > > 4.1.3.2 Idle Timeout > > A Server-FTP process SHOULD have an idle timeout, which > will > terminate the process and close the control connection if > the server is inactive (i.e., no command or data transfer > in > progress) for a long period of time. The idle timeout time > SHOULD be configurable, and the default should be at > least 5 > minutes. > > A client FTP process ("User-PI" in RFC-959) will need > timeouts on responses only if it is invoked from a program. > > DISCUSSION: > Without a timeout, a Server-FTP process may be left > pending indefinitely if the corresponding client > crashes without closing the control connection. > > So, if the draft had specified a BULK_LQ_DATA_TIMEOUT of 5 minutes, we > would NOT be having this discussion, would we? We wouldn't have the part of the discussion about the length of the timeouts. We would still be having the discussion about the clarity of the description of the proposed timeout scheme. Lars > > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: Friday, December 19, 2008 9:37 AM > To: Bernie Volz (volz) > Cc: Thomas Narten; Dhcwg; Ted Lemon; Mark Stapp (mjs); IESG > Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG > review > > Hi, > > On 2008-12-18, at 18:47, Bernie Volz (volz) wrote: >> One of the events I'm worried about is when the server system becomes >> unreachable and thus no data is flowing. > > there are two cases here: > > Case 1: the connection is idle, i.e., neither end has data queued for > transmission in the socket buffers. This is the case where TCP > keepalives help. They let you detect that the other end has > disappeared, which without keepalives you'd only notice when you'd try > to send to or receive from the other end. Question: if your end isn't > trying to send to or receive from the other end, is there any use in > tearing down the connection via a keealive? > > Case 2: the connection is not idle, i.e., at least one end has data > queued for transmission in its socket buffer. TCP keepalives aren'a a > factor here - the TCP stack on the sending side will tear down the > connection after a few sending attempts fail to generate ACKs. On > typical stacks, this happens after a few minutes. > > Is there any need for an additional mechanism in either of these two > cases? > > Lars > >> The other case is when the server is waiting for the first or "next" >> request after having completed one - such as when the relay agent >> becomes unreachable either after opening the connection or after >> having >> received all of the data. >> >> In neither of these cases is data flowing. Hence, keep-alives are >> required or an application timeout to handle the case when no data is >> received over some period of time. > > > >> >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf >> Of Lars Eggert >> Sent: Wednesday, December 17, 2008 2:44 AM >> To: Bernie Volz (volz) >> Cc: Thomas Narten; Mark Stapp (mjs); IESG; Dhcwg; Ted Lemon >> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG >> review >> >> On 2008-12-17, at 7:46, Bernie Volz (volz) wrote: >>> Oh, no way! >>> >>> If the both ends enable keep-alives (some stacks do by default), the >>> there will be periodic probes but they generally don't time out for >>> minutes (I think for most BSD systems it works out to 9 or more if I >>> remember correctly). >> >> TCP keep-alives only kick in when there is no data to send in both >> directions, which isn't the case you're worried about. In your case, >> one end is trying to send data, but the throughput it is achieving >> isn't considered sufficient. The timeouts for failing to make send >> progress are usually on the order of minutes in typical stacks and >> often configurable via setsockopt. (For some more background >> information, see draft-ietf-tcpm-tcp-uto.) >> >>> And, if no keep-alives are sent, if the server crashes, the relay >>> may be >>> waiting forever. >> >> Not if it is trying to send data and not making progress. >> >> Lars >> >> PS: And yes, Thomas note pretty much matches my concerns with the >> document. >> >>> While everyone mentions non-fatal failures -- such as slow servers >>> -- >>> there are lots of other conditions that could cause a significant >>> delay >>> in detecting a downed server or relay agent. >>> >>> These connections are mostly a one-way data flow - relay agent >>> sends a >>> request, server sends lots of responses. >>> >>> TCP is great, don't get me wrong, but sometimes you need faster >>> response >>> than it offers. >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >>> Sent: Wednesday, December 17, 2008 12:04 AM >>> To: Bernie Volz (volz) >>> Cc: Jari Arkko; Thomas Narten; Dhcwg; Mark Stapp (mjs); Lars Eggert; >>> IESG >>> Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG >>> review >>> >>> Why would a broken TCP connection stay up for 10 minutes? >>> Shouldn't >>> it die within 90 seconds if no ACKs are forthcoming from the remote >>> end? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 19 07:59:19 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9473A6A34; Fri, 19 Dec 2008 07:59:19 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B190628C125; Fri, 19 Dec 2008 07:59:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jDlXuinXv4f; Fri, 19 Dec 2008 07:59:17 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 925513A69F6; Fri, 19 Dec 2008 07:59:17 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBJFwGRN000919; Fri, 19 Dec 2008 10:58:16 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBJFx9Fp168558; Fri, 19 Dec 2008 10:59:09 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBJFwX29006937; Fri, 19 Dec 2008 10:58:33 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-146-37.mts.ibm.com [9.76.146.37]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBJFwVjM006875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 10:58:32 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mBJFx6Af018754; Fri, 19 Dec 2008 10:59:06 -0500 Message-Id: <200812191559.mBJFx6Af018754@cichlid.raleigh.ibm.com> To: "Bernie Volz (volz)" In-reply-to: <8E296595B6471A4689555D5D725EBB2109F3C708@xmb-rtp-20a.amer.cisco.com> References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com> <200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com> <8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com> <200812172205.mBHM5RST029771@cichlid.raleigh.ibm.com> <8E296595B6471A4689555D5D725EBB2109F3C708@xmb-rtp-20a.amer.cisco.com> Comments: In-reply-to "Bernie Volz (volz)" message dated "Wed, 17 Dec 2008 18:09:40 -0500." Date: Fri, 19 Dec 2008 10:59:06 -0500 From: Thomas Narten Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks again Bernie for helping clarify. It seems that the real issue is that the client wants to detect the situation where it has already opened a TCP connection, has sent a request to the server, but sometime before the server sends its last response, the server dies. Outside some external timer, the connection hangs for a long time, possibly foerever (if no keepalives are available). We seem to have agreement that terminating a TCP connection open attempt prior to TCP concluding on its own that the connection cannot be established is not necessary. I.e, > BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout Is not necessary and can be removed. Is there agreement on this point? Second, I think it is fine to have application level timeouts. There are justifiable reasons to do that. The only issue that needs discussing (IMO) is reasonable values for such timeouts. What we want to avoid is having the application have such short timeouts that it works at cross-purposes with TCP's underlying reliability/congestion avoidance mechanisms. If we had minimum timeouts of a few minutes, that would be fine (IMO). But the document has 30 second timeouts for this case. That seems low to me, because IMO, you are more likely to react (hastily) to network congestion (or a temporary routing problem) then because the server has died. I would expect server crashes to be much less common than temporary network outages. Right? BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout And, I'm OK with terminating the connection even after just 30 seconds, so long as the recovery is NOT to retry the connection again. The current document suggests doing just that via a MAY. So, bump the timeout to something longer (e.g., 2 or 3 minutes) and IMO that would be OK. And, if someone still wants to argue for a shorter timeout in this case, I still haven't recieved an answer to my question of *why* terminating early in this case and *not* retrying makes sense. Does this clarify the key issues needed to get closure on this document? Slightly longer explanation. We seem to have a classic example of the end-to-end argument at play here: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) Keepalives are such an enhancement, but are not sufficient in this case to correctly implement the application. Indeed, the only way to detect a failed server is send periodic probe packets to test the liveness of both the connection *and* the application at the other end. Note that even TCP keepalives aren't sufficient (in theory). The TCP stack (in the kernel) could be working, the server could still be running, but the application itself may have wedged and be unable to respond. You can only detect that by sending the equivalent of a "are-you-still-there" to the server, with the server returning a "yes-I-am-and-I'm-still-working-on-your-outstanding-request-so-no-need-to-resend". And even here, there are probably edge cases that can't be detected. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 19 08:06:28 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581103A6A41; Fri, 19 Dec 2008 08:06:28 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DE73A69F6; Fri, 19 Dec 2008 08:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwjK+6bO0-8A; Fri, 19 Dec 2008 08:06:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8222B3A68DC; Fri, 19 Dec 2008 08:06:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,249,1228089600"; d="scan'208";a="31560412" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Dec 2008 16:06:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBJG6FAi016240; Fri, 19 Dec 2008 11:06:15 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBJG6Fk8010501; Fri, 19 Dec 2008 16:06:15 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 11:06:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 11:05:32 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210A02A15F@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <200812191559.mBJFx6Af018754@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thread-Index: Aclh8r4JDJUY7d4cRVGvAzjOGBGtwgAAFxUw References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com><8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com><200812172205.mBHM5RST029771@cichlid.raleigh.ibm.com><8E296595B6471A4689555D5D725EBB2109F3C708@xmb-rtp-20a.amer.cisco.com> <200812191559.mBJFx6Af018754@cichlid.raleigh.ibm.com> From: "Bernie Volz (volz)" To: "Thomas Narten" X-OriginalArrivalTime: 19 Dec 2008 16:06:14.0807 (UTC) FILETIME=[B7F60270:01C961F3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4210; t=1229702775; x=1230566775; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Thomas=20Narten=22=20; bh=drsZhqhLFNoFne4DKCML3y6WOuhFo0eR7zoYivSSvAs=; b=LwtoqmImrysb/I3U7fZ60Cs9jJG1erTQy0f44k6EGBYMUIati9ibVov8Ms GS/wQxm4c0hoDm7wWz3d94EF6DRLl2QMEmuGltRPGa14+d3LkXy7iWVN58Re VFjjoO8F5N; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Dhcwg , "Mark Stapp \(mjs\)" , Lars Eggert , IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Mark is the author on this draft, so it is ulimately up to him. But, yes, I think BULK_LQ_CONN_TIMEOUT should be removed. And, BULK_LQ_DATA_TIMEOUT should be 5 minutes (as the default) -- per RFC 1123 4.1.3.2. I see little reason to make it any different. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Friday, December 19, 2008 10:59 AM To: Bernie Volz (volz) Cc: Dhcwg; Mark Stapp (mjs); Lars Eggert; IESG Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review Thanks again Bernie for helping clarify. It seems that the real issue is that the client wants to detect the situation where it has already opened a TCP connection, has sent a request to the server, but sometime before the server sends its last response, the server dies. Outside some external timer, the connection hangs for a long time, possibly foerever (if no keepalives are available). We seem to have agreement that terminating a TCP connection open attempt prior to TCP concluding on its own that the connection cannot be established is not necessary. I.e, > BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout Is not necessary and can be removed. Is there agreement on this point? Second, I think it is fine to have application level timeouts. There are justifiable reasons to do that. The only issue that needs discussing (IMO) is reasonable values for such timeouts. What we want to avoid is having the application have such short timeouts that it works at cross-purposes with TCP's underlying reliability/congestion avoidance mechanisms. If we had minimum timeouts of a few minutes, that would be fine (IMO). But the document has 30 second timeouts for this case. That seems low to me, because IMO, you are more likely to react (hastily) to network congestion (or a temporary routing problem) then because the server has died. I would expect server crashes to be much less common than temporary network outages. Right? BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout And, I'm OK with terminating the connection even after just 30 seconds, so long as the recovery is NOT to retry the connection again. The current document suggests doing just that via a MAY. So, bump the timeout to something longer (e.g., 2 or 3 minutes) and IMO that would be OK. And, if someone still wants to argue for a shorter timeout in this case, I still haven't recieved an answer to my question of *why* terminating early in this case and *not* retrying makes sense. Does this clarify the key issues needed to get closure on this document? Slightly longer explanation. We seem to have a classic example of the end-to-end argument at play here: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) Keepalives are such an enhancement, but are not sufficient in this case to correctly implement the application. Indeed, the only way to detect a failed server is send periodic probe packets to test the liveness of both the connection *and* the application at the other end. Note that even TCP keepalives aren't sufficient (in theory). The TCP stack (in the kernel) could be working, the server could still be running, but the application itself may have wedged and be unable to respond. You can only detect that by sending the equivalent of a "are-you-still-there" to the server, with the server returning a "yes-I-am-and-I'm-still-working-on-your-outstanding-request-so-no-need-t o-resend". And even here, there are probably edge cases that can't be detected. Thomas _______________________________________________ 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 dhcwg-bounces@ietf.org Fri Dec 19 08:11:03 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2FD3A6A51; Fri, 19 Dec 2008 08:11:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93FA13A6A42; Fri, 19 Dec 2008 08:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLw4+0dgZ7IO; Fri, 19 Dec 2008 08:11:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CB3AC3A67E9; Fri, 19 Dec 2008 08:11:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,250,1228089600"; d="scan'208,217";a="31560819" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Dec 2008 16:10:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBJGAqel018158; Fri, 19 Dec 2008 11:10:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJGApb0019952; Fri, 19 Dec 2008 16:10:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 11:10:41 -0500 Received: from [10.86.250.27] ([10.86.250.27]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 11:10:41 -0500 Message-ID: <494BC780.2080902@cisco.com> Date: Fri, 19 Dec 2008 11:10:40 -0500 From: Mark Stapp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <20081210144904.8F0A03A68AE@core3.amsl.com><49415B22.7070008@cisco.com><49418E1C.2030009@piuha.net><200812161753.mBGHrqfu020018@cichlid.raleigh.ibm.com><49480D6F.8020102@cisco.com><200812162224.mBGMOK0Q019006@cichlid.raleigh.ibm.com><49482D25.4080801@piuha.net><8E296595B6471A4689555D5D725EBB2109F3C24E@xmb-rtp-20a.amer.cisco.com><200812171354.mBHDn5ce031396@cichlid.raleigh.ibm.com><8E296595B6471A4689555D5D725EBB2109F3C445@xmb-rtp-20a.amer.cisco.com><200812172205.mBHM5RST029771@cichlid.raleigh.ibm.com><8E296595B6471A4689555D5D725EBB2109F3C708@xmb-rtp-20a.amer.cisco.com> <200812191559.mBJFx6Af018754@cichlid.raleigh.ibm.com> <8E296595B6471A4689555D5D725EBB210A02A15F@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210A02A15F@xmb-rtp-20a.amer.cisco.com> X-OriginalArrivalTime: 19 Dec 2008 16:10:41.0573 (UTC) FILETIME=[56F74550:01C961F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5152; t=1229703052; x=1230567052; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-dhcpv6-bulk-le asequery=20in=20IESG=20review |Sender:=20 |To:=20=22Bernie=20Volz=20(volz)=22=20; bh=VZQPBQDXK9yjJC9KHGZt8jz1rIXd5g11t5zF7JLEZpU=; b=qDbkukDr8veINuuGi/xf1/8hcZqdcosr1aAOYmTrgeUbCnoUJXlg4XFQfF a9kHWHZwXBOtdFxblLvvy3FJd2BG1tMTiTwNJrBGNyCodFai+hy9jIqHokpq SEB/gwUsg+; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Thomas Narten , Dhcwg , IESG , Lars Eggert Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1514774747==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1514774747== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Bernie for helping to clear up the specifics of the issues: I'll issue a new revision.

Regards,
Mark

Bernie Volz (volz) wrote: 
Mark is the author on this draft, so it is ulimately up to him.

But, yes, I think BULK_LQ_CONN_TIMEOUT should be removed.

And, BULK_LQ_DATA_TIMEOUT should be 5 minutes (as the default) -- per
RFC 1123 4.1.3.2. I see little reason to make it any different.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Thomas Narten
Sent: Friday, December 19, 2008 10:59 AM
To: Bernie Volz (volz)
Cc: Dhcwg; Mark Stapp (mjs); Lars Eggert; IESG
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-bulk-leasequery in IESG
review

Thanks again Bernie for helping clarify.

It seems that the real issue is that the client wants to detect the
situation where it has already opened a TCP connection, has sent a
request to the server, but sometime before the server sends its last
response, the server dies. Outside some external timer, the connection
hangs for a long time, possibly foerever (if no keepalives are
available).

We seem to have agreement that terminating a TCP connection open
attempt prior to TCP concluding on its own that the connection cannot
be established is not necessary. I.e,

  
   BULK_LQ_CONN_TIMEOUT  30 secs  Bulk Leasequery connection timeout
    

Is not necessary and can be removed.  Is there agreement on this
point?

Second, I think it is fine to have application level timeouts. There
are justifiable reasons to do that. The only issue that needs
discussing (IMO) is reasonable values for such timeouts. What we want
to avoid is having the application have such short timeouts that it
works at cross-purposes with TCP's underlying reliability/congestion
avoidance mechanisms. If we had minimum timeouts of a few minutes,
that would be fine (IMO). But the document has 30 second timeouts for
this case. That seems low to me, because IMO, you are more likely to
react (hastily) to network congestion (or a temporary routing problem)
then because the server has died. I would expect server crashes to be
much less common than temporary network outages. Right?

   BULK_LQ_DATA_TIMEOUT  30 secs  Bulk Leasequery data timeout

And, I'm OK with terminating the connection even after just 30
seconds, so long as the recovery is NOT to retry the connection
again. The
current document suggests doing just that via a MAY.

So, bump the timeout to something longer (e.g., 2 or 3 minutes) and
IMO that would be OK.

And, if someone still wants to argue for a shorter timeout in this
case, I still haven't recieved an answer to my question of *why*
terminating early in this case and *not* retrying makes sense.

Does this clarify the key issues needed to get closure on this
document?

Slightly longer explanation.

We seem to have a classic example of the end-to-end argument at play
here:

      The function in question can completely and correctly be
      implemented only with the knowledge and help of the application
      standing at the end points of the communication
      system. Therefore, providing that questioned function as a
      feature of the communication system itself is not
      possible. (Sometimes an incomplete version of the function
      provided by the communication system may be useful as a
      performance enhancement.)

Keepalives are such an enhancement, but are not sufficient in this
case to correctly implement the application.

Indeed, the only way to detect a failed server is send periodic probe
packets to test the liveness of both the connection *and* the
application at the other end. Note that even TCP keepalives aren't
sufficient (in theory). The TCP stack (in the kernel) could be
working, the server could still be running, but the application itself
may have wedged and be unable to respond. You can only detect that by
sending the equivalent of a "are-you-still-there" to the server, with
the server returning a
"yes-I-am-and-I'm-still-working-on-your-outstanding-request-so-no-need-t
o-resend". And
even here, there are probably edge cases that can't be detected.

Thomas
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--===============1514774747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1514774747==-- From dhcwg-bounces@ietf.org Fri Dec 19 09:02:04 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917663A6A5E; Fri, 19 Dec 2008 09:02:04 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C6C3A6A4D for ; Fri, 19 Dec 2008 08:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.322 X-Spam-Level: X-Spam-Status: No, score=-5.322 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txgTua7SpiSh for ; Fri, 19 Dec 2008 08:59:56 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5F7EF3A67AC for ; Fri, 19 Dec 2008 08:59:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,250,1228089600"; d="jpg'145?scan'145,208,217,145";a="216379363" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Dec 2008 16:59:48 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBJGxmwY030574 for ; Fri, 19 Dec 2008 08:59:48 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJGxl6G020411 for ; Fri, 19 Dec 2008 16:59:48 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 11:59:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 11:58:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: draft-ietf-dhc-vpn-option-09 Thread-Index: Aclh+xQTYm/w+biYTAqZ487xxFJOMw== From: "Neil Russell (nrussell)" To: X-OriginalArrivalTime: 19 Dec 2008 16:59:47.0159 (UTC) FILETIME=[32AC0670:01C961FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6727; t=1229705988; x=1230569988; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=nrussell@cisco.com; z=From:=20=22Neil=20Russell=20(nrussell)=22=20 |Subject:=20re=3A=20draft-ietf-dhc-vpn-option-09 |Sender:=20; bh=kjHT2Y328OWgXPoaaBco695eUaL5SL3YBa7Qe1ZjuYc=; b=NATQMbDE83QigYS+uKrnG8gqF2EHSDPrDTb1DqRZPVjfHKWy3qClXD7WsQ VqPRUmrb1s3FsWj/tIWiv8c9z/Gij0hXWVqOduCREp/vDS+V/yX52th/zA2K zEbOlECMGu; Authentication-Results: sj-dkim-2; header.From=nrussell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2073650654==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2073650654== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C961FB.147C3B8E"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C961FB.147C3B8E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C961FB.147C3B8E" ------_=_NextPart_002_01C961FB.147C3B8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read the draft and believe that it should move forward in the standards process. --N =09 Neil Russell Techical Leader Network Management Technology Group nrussell@cisco.com=20 Phone: 978-936-1204 Mobile: 978-239-4429 1414 Massachusetts Avenue Boxborough MA 01719 www.cisco.com =20 =20 ------_=_NextPart_002_01C961FB.147C3B8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read the draft and believe that it should move forward in the standards=20 process.

--N
=
Neil=20 Russell
Techical=20 Leader
Network Management = Technology=20 Group

nrussell@cisco.com =
Phone:=20 978-936-1204
Mobile:=20 978-239-4429
1414=20 Massachusetts Avenue
Boxborough MA 01719

www.cisco.com

 
------_=_NextPart_002_01C961FB.147C3B8E-- ------_=_NextPart_001_01C961FB.147C3B8E Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <768165816@19122008-2091> Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABEAGYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIFuR2 p3lFe1Wtyj+Glyp/grXmZ5/KiqA28AgFcc+uafsXA4qcICTiM0jIAcEEUJlcpAYgegprRcdKm2j1 oKjHWr5mLlRAY+me1WIFB0q4TB4njbP1Vh/SmEAd6t22P7MvCBwHi/8AZ6zqT0XqbUoq79DPZAMf T0qS1dVuY9xwpbafoeD+hpxYnFNYnBGP0pt3VhKNnciYFGZWPKnBFHmJ3xVm8YNcmQKCJQJOnqMn 9c1WJGfuikpXVwcbOxC6wO2eM+1FSbVJ+6KKvmFymgVX+9+lJgD+MU4RDHWgxgda5nMvkXYSNiMk SYpzOH4LD8KSN4LY+bPs8sAlg54x3P4VoW3xH8GaZcN9llkYOAGUWZI3DjIJPHboKzlUcXorm8Ka ktXYzQgz/EfoKawAIGD+VdJaeOtJntRJprSXIiU8vCVJ+ppYvGqSRNt06Nm3lgWPI/SoWIm3axo8 NFK9zlyVUZ2SEY3cLnitldLktvC893KrI0zpmI9UAPBP13dKsP4nvZInjhit4N+R8i84Pb+dVxqE l1pd1YGGCCGNBIqxJsAIZRjFN1JvcSpwWxiNtwOGpMDrhsVKAqngk0hB67jW6mzBwQSbTbQtsb5d ydffI/8AQv0qswXsCPxq6NzW8qZztw4/kf5j8qrFCe4pKVhyimyFdobBwfxoqRUKt1H5UUnN3HFR tqSyzvDOil4wj8AHOc/WmrdRgOzzlijEMqL6dulcXPqOuLp0Fxc3Enk3HKEqPmAOM/nW54Qt7/xF eCAzEwDiRmVQc9tvHXvWE3ZNs6IRvKxe+0IInllbzIBGBM8/AUuDgegHFZcdxpUOvQwHSobqBT+9 aAbWIx146/5Fex2HhyGzsXt7iOK5LdDJGhxznnjBqW10xbLy/s8aQMmcGJUHX1O3muf2/kbqmk9G eTw/btW1N/smkvYWzyERgxsAo9Tj1rTbwfr7Gc2jxybztf5ygGR1znII9vWvVWWW4hMc13OqsMHa wUn8lrMPhqwF8L0CY3Qj8sTNKS+3GMZx6VPtH0LVn8SOBtra3gRvPvrf7SzguPtcZXOAPl+b1q3G kyanLZj7JJNKvkNEbtBIGyDwuevHSurTwPohbLaepB9SRir48H6NG3n/AGPMoO7fubcT65z1o9pJ g1ST2/r7zhP7MvFFwJLZEa3I8wGQfID0zzVO9D2h8uUCKTIADAg/rXoc3h/St5drJXZvvM4JJ+uS c0q6Xo8ZEklpb7x0YxqcfnVKu1uQ6MHqjzJ3mLhbRGmZwBsViCQfT8KfKjwyNHINrL1Xdux+NdP4 91kaB4aka0hVLi4fyYiE7Hknj0GfzFeON4k1c4wwUe0QropSlNXMKsFF2R25b0NFcSviHV2YguB/ 2xFFa2Zzum3sJeXYvCsUsjRxW8axqvlnkZx0/WvQfCvifTdA05Lex0nUZ2x80hiQFvXqa8+1CNQy edKRgAAPzx7V1ug63fWsSQ2OmrcxcAsqk9s+9c9eDcdDsoSjfU7VPiDPNxHoF5n/AGpYh/7NUL/E PUVcInhmZyemZVwfyzTLHWGmhn+2aTNA8a5XbFuDnOMdBinW+qxSyhJNLu0LHAYWxx+JxXFqt4/j /wAE6+WPf+vuJB4/8Sn/AFXg2V/Qhif1xTJvHfjIpkeD3QD/AGmrRXU7eD92trdrjqfJwKZLfWjO EUgPjO1gOPr6U/aJfZ/Mn2V+pit438ZSDP8AwjgTP/PVZWx+Iqwmu/EKSMtDZ2ESn+8GGPzNWG1b R0YeZqaK5/5ZjBB/ELU0eoDzNtpqNp6eW/Y/TcD+lP2naKK9krasxrjU/iaRuEtmh7bSn9c1VaHx 3eDfca1BC5/hAH8wK6a4j1YLkXmmyKRwPJb/ABPFUbk38Kks9pj+7FbHP6mj2jfRfcL2aXc5vUtJ 1lLDzdU1Rb5omJC+YflGOwaubkMZ6qQfriuo1XVIpIjELUxynP71YlB/rXIXM6s/3GkAHUjBruw6 lJe8ceISi7okOzORn+dFUfNG7iJx/wACorpdNHLd9xmsqCiPyDwK2PC1zPax7kkLDnh+en60UVhU /hm9F+8j0XTtSnm0sk7V3MAduauxjzAhZmzjsetFFeTI9SJaupTDp5ZVB7YOcfpXI65q8tneBo4L cnZyWQ5PHqDn9aKKIblLYw/7Ylfa7W8BJ7fMB/6FVyLUzcLdXUlnamSLaRmPO7J75OaKK6TFt3Me 81a6bew8tNxAwqAYHtVGS8upJGBuZQAcAK5FFFdtKKtscddvmJBqN8qlftkpUqeGOcVWvA8dwR5z twDk49PpRRXZCKT0Ryyk2tWVgz55dj+NFFFXJK5nc//Z ------_=_NextPart_001_01C961FB.147C3B8E-- --===============2073650654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============2073650654==-- From dhcwg-bounces@ietf.org Fri Dec 19 11:35:49 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1306B3A6A6B; Fri, 19 Dec 2008 11:35:49 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FBE3A6A6B for ; Fri, 19 Dec 2008 11:35:47 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrmZepy2yzkK for ; Fri, 19 Dec 2008 11:35:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4D8113A6A49 for ; Fri, 19 Dec 2008 11:35:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,250,1228089600"; d="scan'208";a="31623185" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Dec 2008 19:35:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBJJZcVj030098 for ; Fri, 19 Dec 2008 14:35:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJJZcvQ028319 for ; Fri, 19 Dec 2008 19:35:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 14:35:37 -0500 Received: from [10.86.251.130] ([10.86.251.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 14:35:37 -0500 Message-ID: <494BF789.40609@cisco.com> Date: Fri, 19 Dec 2008 14:35:37 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: dhcwg@ietf.org X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 19 Dec 2008 19:35:37.0681 (UTC) FILETIME=[F8047410:01C96210] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=549; t=1229715338; x=1230579338; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joshl@cisco.com; z=From:=20Josh=20Littlefield=20 |Subject:=20Re=3A=20[dhcwg]=20draft-ietf-dhc-vpn-option-09 |Sender:=20 |To:=20dhcwg@ietf.org; bh=cez3aax20XY+prm1Mdocd3hGBfORQztm5RT7xCfKyrs=; b=XVf19DgoifoZDoUrmlhEOgjle/SLEUjN+hfKwKwWHqf5Jt/PekyIQK+iis c6YZliL474tlV4lqO4N1CA2kZ9bg583KvMFAnBxWci7QmEYIuhyvBelbAfuM R3iaNXMRZP; Authentication-Results: rtp-dkim-1; header.From=joshl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have reviewed the referenced draft (draft-ietf-dhc-vpn-option-09.txt) and fully support it's publication. I have submitted very minor editorial comments (missing or extra words) to the authors for correction during the final editing process. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nknen@alliance.co.jp Fri Dec 19 11:54:15 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B920C3A6A73 for ; Fri, 19 Dec 2008 11:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.115 X-Spam-Level: X-Spam-Status: No, score=-35.115 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OufaYboqi1nY for ; Fri, 19 Dec 2008 11:54:15 -0800 (PST) Received: from af.pentagon.mil (unknown [189.200.83.1]) by core3.amsl.com (Postfix) with SMTP id 4C0A73A6A6B for ; Fri, 19 Dec 2008 11:54:13 -0800 (PST) To: Subject: Dear dhcwg-archive, Dec 80% 0FF From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219195414.4C0A73A6A6B@core3.amsl.com> Date: Fri, 19 Dec 2008 11:54:13 -0800 (PST) Dear Customer!
Lovers package at discount price!
Discount price store: ID 58436
http://ispurpose.com/

Pfizer is a licensee of the TRUSTe Privacy Program.
© 2001-2008 Pfizer Inc. All rights reserved. From dhcwg-bounces@ietf.org Fri Dec 19 13:19:29 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C7D3A69FF; Fri, 19 Dec 2008 13:19:29 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466D73A69FF for ; Fri, 19 Dec 2008 13:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csyT-5UDCOhj for ; Fri, 19 Dec 2008 13:19:27 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 700CB3A69FC for ; Fri, 19 Dec 2008 13:19:27 -0800 (PST) Received: from localhost ([127.0.0.1]:51723 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1LDmkc-0003kn-Ft; Fri, 19 Dec 2008 22:19:14 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: raj@cisco.com, john_brzozowski@cable.comcast.com, rdroms@cisco.com X-Trac-Project: dhc Date: Fri, 19 Dec 2008 21:19:14 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://svn.tools.ietf.org/wg/dhc/trac/ticket/14#comment:3 Message-ID: <066.be5fd19b11df5d6775a6c925fab804ad@tools.ietf.org> References: <057.ba22aec0b929c1999210ae210cb1ccdf@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <057.ba22aec0b929c1999210ae210cb1ccdf@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: raj@cisco.com, john_brzozowski@cable.comcast.com, rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #14: Response to WG last call on draft-ietf-dhc-subnet-alloc X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #14: Response to WG last call on draft-ietf-dhc-subnet-alloc ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: raj@cisco.com Type: defect | Status: closed Priority: major | Milestone: Component: subnet-alloc | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by raj@cisco.com): * status: new => closed * resolution: => fixed -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Dec 19 14:59:49 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6883A67E9; Fri, 19 Dec 2008 14:59:49 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F013A67E9 for ; Fri, 19 Dec 2008 14:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLAQR4GuXmZh for ; Fri, 19 Dec 2008 14:59:44 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CD4CE3A63EC for ; Fri, 19 Dec 2008 14:59:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,251,1228089600"; d="scan'208";a="31610332" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Dec 2008 22:59:35 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBJMxZvG026874; Fri, 19 Dec 2008 17:59:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJMxZq5028850; Fri, 19 Dec 2008 22:59:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 17:59:35 -0500 Received: from kkinnear-wxp01.cisco.com ([10.86.242.75]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 17:59:34 -0500 Message-Id: <4.3.2.7.2.20081219173300.0366e2e0@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Dec 2008 17:59:50 -0500 To: Bharat Joshi , "dhcwg@ietf.org" From: Kim Kinnear In-Reply-To: <31D55C4D55BEED48A4459EB64567589A0CC8E90FB1@BLRKECMBX02.ad. infosys.com> Mime-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2008 22:59:35.0033 (UTC) FILETIME=[760C2E90:01C9622D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3441; t=1229727575; x=1230591575; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20Lease=20query=20by=20remote-i d |Sender:=20 |To:=20Bharat=20Joshi=20,=20=22dh cwg@ietf.org=22=20; bh=HMZi8Sfv8/g8QoA8Kr91zho/Q2xosuLGuVQNGHfxI4E=; b=lf/sWqCQEms7zP1doLqZjRJftycsaCrGPDMXexBKjkzQ1QyeJR1tDXsFD6 OysX9S5WXL3MyAQl3cj4tOC6RWHnKbjMtXBiUyZ+tnclMjiOlj5f+IxSLDSy Qt0DdpXC4k; Authentication-Results: rtp-dkim-1; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: kkinnear@cisco.com Subject: Re: [dhcwg] Lease query by remote-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bharat, I've recently reviewed draft-ietf-dhc-leasequery-by-remote-id-00.txt. I had the following comments: Section 5, second to last paragraph: "In addition, it may supply additional ...". I believe this should probably be "... it SHOULD supply" or maybe "... it MUST supply", but a lowercase "may" isn't helpful. Section 5, last paragraph: Every sentence should begin with "The ...". "[The] server replies with a DHCPLEASEUNASSIGNED if it has information of the said remote ID but no lease is assigned for the same". Andre Kostur brought this up too -- you said to him: >We assumed that a DHCP server would be able to figure out if it is serving a given remote-id or not. So it should be able to reply with DHCPLEASEUNASSIGNED for those which it may be serving but does not have any active lease associated with it. While it is certainly possible that some DHCP servers keep track of this stuff independent of active leases associated with things like the remote-id, our server does not do this in a consistent way. We keep information like this associated only with leases, and if we have leases that are not active but were once active with a particular remote-id, this would be "remembered". But if no leases are in that situation, we would have no memory of any remote-id's we've ever served. Since the remote-id is defined to be opaque {from RFC 3046): > The option SHOULD be > considered an opaque value, with policies based on exact string match > only; that is, the option SHOULD NOT be internally parsed by the > server. there are few reasons (other than to support this draft) why a DHCP server would keep around a separate list of remote-id's that it "serves" but for which it has no currently active addresses. DHCP servers are performance limited, and this data isn't interesting enough to keep around unless you have a good reason for doing so. All of this is to say that I think that the above paragraph should say: "[The] server MUST reply with a DHCPLEASEUNASSIGNED if it has information of the said remote ID but no lease is assigned for the same. The server [MAY | SHOULD] keep track of the remote ID values for which it has currently active leases as well as any which it has served in the recent past but for which it has no currently active leases". I can see this as a MAY or SHOULD, but certainly not a MUST. Section 6.3, last paragraph, last sentence: "... server not only know[s] the ..." Section 6.9. "The lease binding data storage requirements are the same as those specified in RFC 4388 [RFC4388]." I disagree. In order to answer these queries efficiently, the DHCP server would have to at least add an index based on remote-id value to the lease state database. Whether this database is on-disk or in-memory, some server-wide index capability based on remote-id is necessary to be efficient in implementing this draft. Not only does this need to be mentioned here in this section, but in my mind that is the biggest problem with this draft -- the additional data storage requirement burden (not space so much as time) that this draft places on every DHCP server which implements it. And this cost in processing time is permanent even if no relay agent ever uses this query. Regards -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From maaritsuess@adventisthealthcare.com Sat Dec 20 03:11:19 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86833A6838 for ; Sat, 20 Dec 2008 03:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MQbpPVGzMeA for ; Sat, 20 Dec 2008 03:11:19 -0800 (PST) Received: from ahnepee.com (unknown [58.147.17.122]) by core3.amsl.com (Postfix) with SMTP id 2E74C3A67FB for ; Sat, 20 Dec 2008 03:11:17 -0800 (PST) To: Subject: We seek for you all day! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081220111118.2E74C3A67FB@core3.amsl.com> Date: Sat, 20 Dec 2008 03:11:17 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lanad@3megs.com Sat Dec 20 05:55:32 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD943A6827 for ; Sat, 20 Dec 2008 05:55:32 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): Subject: Canadian Store \302\256 Official Site\n X-Spam-Flag: NO X-Spam-Score: -16.061 X-Spam-Level: X-Spam-Status: No, score=-16.061 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_CANADIAN=0.5, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWD+GYWrALRD for ; Sat, 20 Dec 2008 05:55:31 -0800 (PST) Received: from a-linkuf.com (unknown [189.123.207.254]) by core3.amsl.com (Postfix) with SMTP id A69BA3A6A1F for ; Sat, 20 Dec 2008 05:55:30 -0800 (PST) To: Subject: Canadian Store ® Official Site From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081220135530.A69BA3A6A1F@core3.amsl.com> Date: Sat, 20 Dec 2008 05:55:30 -0800 (PST) Dear Customer!
Lovers package at discount price!
Discount price store: ID 21280
http://ispurpose.com/

Pfizer is a licensee of the TRUSTe Privacy Program.
© 2001-2008 Pfizer Inc. All rights reserved. From karson@aldec.com Sun Dec 21 20:39:15 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E9D3A692D for ; Sun, 21 Dec 2008 20:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8ja+2e-ZK35 for ; Sun, 21 Dec 2008 20:39:14 -0800 (PST) Received: from CBL217-132-224-6.bb.netvision.net.il (CBL217-132-224-6.bb.netvision.net.il [217.132.224.6]) by core3.amsl.com (Postfix) with SMTP id 56E783A68A4 for ; Sun, 21 Dec 2008 20:39:12 -0800 (PST) To: Subject: Awesome presents to give From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222043913.56E783A68A4@core3.amsl.com> Date: Sun, 21 Dec 2008 20:39:12 -0800 (PST) Harmonize your style with more fashionable accessories! From dhcwg-bounces@ietf.org Sun Dec 21 21:01:57 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE1E3A6872; Sun, 21 Dec 2008 21:01:57 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4830C3A6872 for ; Sun, 21 Dec 2008 21:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_220=2.118] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x608-dOW4xTq for ; Sun, 21 Dec 2008 21:01:55 -0800 (PST) Received: from Kecgate03.infosys.com (kecgate03.progeon.com [220.227.179.21]) by core3.amsl.com (Postfix) with ESMTP id 5703F3A67AE for ; Sun, 21 Dec 2008 21:01:53 -0800 (PST) X-TM-IMSS-Message-ID: <23c1ba4f00047cbb@Kecgate03.infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by Kecgate03.infosys.com ([220.227.179.21]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 23c1ba4f00047cbb ; Mon, 22 Dec 2008 10:32:20 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Mon, 22 Dec 2008 10:31:35 +0530 From: Bharat Joshi To: Kim Kinnear , "dhcwg@ietf.org" Date: Mon, 22 Dec 2008 10:31:35 +0530 Thread-Topic: [dhcwg] Lease query by remote-id Thread-Index: AcliLXu3qu830YQ6QDmsYsTXgpFBrgBujKcg Message-ID: <46EDFFB40E4ABC4BB72D47CF34B186E30C84900C5F@BLRKECMBX02.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A0CC8E90FB1@BLRKECMBX02.ad. infosys.com> <4.3.2.7.2.20081219173300.0366e2e0@email.cisco.com> In-Reply-To: <4.3.2.7.2.20081219173300.0366e2e0@email.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [dhcwg] Lease query by remote-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Kim, Thanks a lot for your comments. Please see my response in line. I will come out with a new revision soon. Regards, Bharat > Bharat, > > I've recently reviewed draft-ietf-dhc-leasequery-by-remote-id-00.txt. > > I had the following comments: > > Section 5, second to last paragraph: > > "In addition, it may supply additional ...". I believe this > should probably be "... it SHOULD supply" or maybe "... it > MUST supply", but a lowercase "may" isn't helpful. > Ok. I can change this to 'SHOULD'. Actually we have taken this wording from RFC 4388. We agreed with this wordings because there may be only one IP address associated with the passed remote-id. In RFC 4388, it is available in section 5, under "Query by MAC address". > Section 5, last paragraph: > > Every sentence should begin with "The ...". > > "[The] server replies with a DHCPLEASEUNASSIGNED if it has > information of the said remote ID but no lease is assigned for > the same". Andre Kostur brought this up too -- you said to > him: Ok. I will fix this. > >We assumed that a DHCP server would be able to figure out if it is > serving a given remote-id or not. So it should be able to reply with > DHCPLEASEUNASSIGNED for those which it may be serving but does not have > any active lease associated with it. > > While it is certainly possible that some DHCP servers keep > track of this stuff independent of active leases associated > with things like the remote-id, our server does not do this in > a consistent way. We keep information like this associated > only with leases, and if we have leases that are not active but > were once active with a particular remote-id, this would be > "remembered". But if no leases are in that situation, we would > have no memory of any remote-id's we've ever served. Since the > remote-id is defined to be opaque {from RFC 3046): > > > The option SHOULD be > > considered an opaque value, with policies based on exact string match > > only; that is, the option SHOULD NOT be internally parsed by the > > server. > > there are few reasons (other than to support this draft) why a > DHCP server would keep around a separate list of remote-id's > that it "serves" but for which it has no currently active > addresses. DHCP servers are performance limited, and this data > isn't interesting enough to keep around unless you have a good > reason for doing so. > > All of this is to say that I think that the above paragraph > should say: > > "[The] server MUST reply with a DHCPLEASEUNASSIGNED if it has > information of the said remote ID but no lease is assigned for > the same. The server [MAY | SHOULD] keep track of the remote ID values > for which it has currently active leases as well as any which > it has served in the recent past but for which it has no > currently active leases". > > I can see this as a MAY or SHOULD, but certainly not a MUST. Ok. We were thinking that a DHCP server may be pre-configured to have all the remote-ids it will serve. This could be used for IP address allocation or other policy enforcements. So if a DHCP server maintains such information, it can do what we have suggested. But I agree that there may be DHCP server's which do not do this or are not capable of doing this. I will change it to what you have suggested. > Section 6.3, last paragraph, last sentence: > > "... server not only know[s] the ..." Will fix this. > Section 6.9. > > "The lease binding data storage requirements are the same as > those specified in RFC 4388 [RFC4388]." > > I disagree. In order to answer these queries efficiently, the > DHCP server would have to at least add an index based on > remote-id value to the lease state database. Whether this > database is on-disk or in-memory, some server-wide index > capability based on remote-id is necessary to be efficient > in implementing this draft. Yes. I agree. > Not only does this need to be mentioned here in this section, > but in my mind that is the biggest problem with this draft -- > the additional data storage requirement burden (not space so > much as time) that this draft places on every DHCP server which > implements it. And this cost in processing time is permanent > even if no relay agent ever uses this query. Ok. I will add this information in the protocol overview as well as under this section so that it becomes explicit. I agree that for a DHCP server to respond effeciently, it needs to index the allocated lease using remote-id as well. I agree that this increases the processing required in DHCP server but if a DHCP server supports query by remote-id, it need not support query-by-mac-address and query-by-client-identifier which will surely help in saving some time as well as space. In any case, if a DHCP server supports DHCPv4 Bulk Lease query, it would need to do the above so the lease database can be used by both UDP/TCP based lease query. **************** 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 From mail@anamaxinc.com Mon Dec 22 04:00:23 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F513A6774 for ; Mon, 22 Dec 2008 04:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.679 X-Spam-Level: X-Spam-Status: No, score=-14.679 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvIfOWLmh0Ce for ; Mon, 22 Dec 2008 04:00:17 -0800 (PST) Received: from 189-92-78-29.3g.claro.net.br (189-92-78-29.3g.claro.net.br [189.92.78.29]) by core3.amsl.com (Postfix) with SMTP id 910DD3A6945 for ; Mon, 22 Dec 2008 03:59:57 -0800 (PST) To: Subject: Can't you answer the call? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222120002.910DD3A6945@core3.amsl.com> Date: Mon, 22 Dec 2008 03:59:57 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From naciomccrackenstabile@alliance-group.com Mon Dec 22 04:13:56 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173AB3A68A7 for ; Mon, 22 Dec 2008 04:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.55 X-Spam-Level: X-Spam-Status: No, score=-34.55 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3WT93323FRP for ; Mon, 22 Dec 2008 04:13:50 -0800 (PST) Received: from 21peixun.com (unknown [94.178.18.220]) by core3.amsl.com (Postfix) with SMTP id 82CCA3A67AD for ; Mon, 22 Dec 2008 04:13:45 -0800 (PST) X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 152832, updated: 13.11.2006] To: Subject: Reduce all undesired symptoms From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222121347.82CCA3A67AD@core3.amsl.com> Date: Mon, 22 Dec 2008 04:13:45 -0800 (PST) Go to site now! From pablo.ortizo@alicante-ayto.es Mon Dec 22 06:11:53 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64C13A69E0 for ; Mon, 22 Dec 2008 06:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.658 X-Spam-Level: X-Spam-Status: No, score=-12.658 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nauhW8PxcU1X for ; Mon, 22 Dec 2008 06:11:46 -0800 (PST) Received: from 189-015-23-137.xd-dynamic.ctbcnetsuper.com.br (189-015-23-137.xd-dynamic.ctbcnetsuper.com.br [189.15.23.137]) by core3.amsl.com (Postfix) with SMTP id BF4133A694C for ; Mon, 22 Dec 2008 06:11:43 -0800 (PST) To: Subject: Why did you leave me? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222141144.BF4133A694C@core3.amsl.com> Date: Mon, 22 Dec 2008 06:11:43 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lescocharlena@afaq.org Tue Dec 23 04:03:59 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D877F3A6B00 for ; Tue, 23 Dec 2008 04:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.563 X-Spam-Level: X-Spam-Status: No, score=-31.563 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oxK8u--p8wf for ; Tue, 23 Dec 2008 04:03:59 -0800 (PST) Received: from aqh246.neoplus.adsl.tpnet.pl (aqh246.neoplus.adsl.tpnet.pl [83.26.167.246]) by core3.amsl.com (Postfix) with SMTP id 90C913A680A for ; Tue, 23 Dec 2008 04:03:55 -0800 (PST) To: Subject: Strength and largeness for you From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223120356.90C913A680A@core3.amsl.com> Date: Tue, 23 Dec 2008 04:03:55 -0800 (PST) Gain about 3 inches in length and make it a lot wider, too! From mail@andreas-bracht.de Tue Dec 23 06:35:54 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487633A691F for ; Tue, 23 Dec 2008 06:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.599 X-Spam-Level: X-Spam-Status: No, score=-35.599 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yut773kOqBw7 for ; Tue, 23 Dec 2008 06:35:53 -0800 (PST) Received: from gargamel.bpcentrum.net (gargamel.bpcentrum.net [193.142.113.195]) by core3.amsl.com (Postfix) with SMTP id A668A3A68B7 for ; Tue, 23 Dec 2008 06:35:51 -0800 (PST) To: Subject: I need you, urgently! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223143552.A668A3A68B7@core3.amsl.com> Date: Tue, 23 Dec 2008 06:35:51 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From karst.skalski@acepta.com Tue Dec 23 06:41:58 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65CD3A691F for ; Tue, 23 Dec 2008 06:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.653 X-Spam-Level: X-Spam-Status: No, score=-12.653 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrYuPlrkPv0o for ; Tue, 23 Dec 2008 06:41:58 -0800 (PST) Received: from host70-67-dynamic.10-87-r.retail.telecomitalia.it (host70-67-dynamic.10-87-r.retail.telecomitalia.it [87.10.67.70]) by core3.amsl.com (Postfix) with SMTP id DCD2D3A6813 for ; Tue, 23 Dec 2008 06:41:55 -0800 (PST) To: Subject: Become more strong and mighty From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223144156.DCD2D3A6813@core3.amsl.com> Date: Tue, 23 Dec 2008 06:41:55 -0800 (PST) Your life could really change today! Start now! From dhcwg-bounces@ietf.org Tue Dec 23 10:13:20 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715B63A6B1E; Tue, 23 Dec 2008 10:13:20 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9823A6B1C for ; Tue, 23 Dec 2008 10:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW0JjxO8njnB for ; Tue, 23 Dec 2008 10:13:18 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id AC6CA3A6452 for ; Tue, 23 Dec 2008 10:13:17 -0800 (PST) Received: from localhost ([127.0.0.1]:60970 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1LFBkg-00084a-8C; Tue, 23 Dec 2008 19:13:06 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: kkinnear@cisco.com, rdroms@cisco.com X-Trac-Project: dhc Date: Tue, 23 Dec 2008 18:13:06 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/19 Message-ID: <057.4e57fcaf655618870eeeba8f68122886@tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: kkinnear@cisco.com, rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: [dhcwg] [dhc] #19: Minor issues that we might want to consider in this document X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #19: Minor issues that we might want to consider in this document ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: kkinnear@cisco.com Type: defect | Status: new Priority: minor | Milestone: Component: vpn-option | Version: Severity: In WG Last Call | Keywords: ------------------------------+--------------------------------------------- See http://www.ietf.org/mail-archive/web/dhcwg/current/msg09348.html and two followups for details. -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 10:16:32 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B767B3A6B2B; Tue, 23 Dec 2008 10:16:32 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F323A6B2B for ; Tue, 23 Dec 2008 10:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNowbcXHIuf4 for ; Tue, 23 Dec 2008 10:16:31 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 18B923A682E for ; Tue, 23 Dec 2008 10:16:30 -0800 (PST) Received: from localhost ([127.0.0.1]:33019 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1LFBnj-0001gE-Tn; Tue, 23 Dec 2008 19:16:15 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Tue, 23 Dec 2008 18:16:15 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/15#comment:2 Message-ID: <066.2929c9392375962784a22f87222d6c08@tools.ietf.org> References: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: vpn-option | Version: Severity: In WG Last Call | Resolution: Keywords: | ------------------------------+--------------------------------------------- Old description: > The WG last call for draft-ietf-dhc-vpn-option will terminate at 1700PDT > on 12/19/2008. > > The discussion thread for this WG last call is at http://www.ietf.org > /mail-archive/web/dhcwg/current/msg09264.html > > A comment from the previous WG last call, > http://trac.tools.ietf.org/wg/dhc/trac/ticket/12, will be considered as > part of this WG last call New description: The WG last call for draft-ietf-dhc-vpn-option will terminate at 1700PDT on 12/19/2008. The discussion thread for this WG last call is at http://www.ietf.org /mail-archive/web/dhcwg/current/msg09264.html A reminder for the last call is at: http://www.ietf.org/mail- archive/web/dhcwg/current/msg09327.html A comment from the previous WG last call, http://trac.tools.ietf.org/wg/dhc/trac/ticket/12, will be considered as part of this WG last call -- Comment(by rdroms@cisco.com): Results from WG last call: Bernie Volz supports the doc, with a minor issue in http://trac.tools.ietf.org/wg/dhc/trac/ticket/19 However, as of 12/23/08, we still have insuffucient support to move the document forward. -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 10:31:05 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB713A67DA; Tue, 23 Dec 2008 10:31:05 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D819728C151 for ; Tue, 23 Dec 2008 10:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryU8YjKV9-ro for ; Tue, 23 Dec 2008 10:31:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C3B483A67A1 for ; Tue, 23 Dec 2008 10:31:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,273,1228089600"; d="scan'208";a="31917854" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Dec 2008 18:30:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBNIUsIF013453 for ; Tue, 23 Dec 2008 13:30:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBNIUsDd029771 for ; Tue, 23 Dec 2008 18:30:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 13:30:54 -0500 Received: from [161.44.65.106] ([161.44.65.106]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 13:30:54 -0500 Message-Id: <62F82FD8-891C-4AF7-9E4F-4E7AB270089A@cisco.com> From: Ralph Droms To: dhcwg@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 13:30:54 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Dec 2008 18:30:54.0178 (UTC) FILETIME=[96EBEC20:01C9652C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1444; t=1230057054; x=1230921054; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20*EXTENSION*=3A=20dhc=20WG=20last=20call=20on=20 draft-ietf-dhc-vpn-option-09.txt |Sender:=20 |To:=20dhcwg@ietf.org; bh=Y+IZon4InOp9F66XyijQlultpbUAlHbt4nuKYoY8z5s=; b=jqeZoMPiPreM+6+lh/UpqEBBtA5mcXSrgpoVtUo7ghA0/KqHywfnjYACJs 6w9qdUcL3ITJhDc5UDVu4LbXTQBEJVlnve+i1vXsKWMH6uaP1VMeD5e557fB IyatiFkFkV; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [dhcwg] *EXTENSION*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org EXTENSION: This WG last call will be extended to January 9, 2009. We still need at least one more review before the document can be advanced to the IESG. This message announces a WG last call on "Virtual Subnet Selection Options for DHCPv4 and DHCPv6" . The last call will conclude at 1700PDT on January 9, 2009. This document is intended for publication as a Draft Standard. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-dhc-vpn-option-09.txt defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-09.txt - John Brzozowski, Ralph Droms dhc WG chairs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 10:45:03 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBA73A67D0; Tue, 23 Dec 2008 10:45:03 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C39E3A6452 for ; Tue, 23 Dec 2008 10:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rRqzY+2JV0G for ; Tue, 23 Dec 2008 10:45:00 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 4CE7D3A67D0 for ; Tue, 23 Dec 2008 10:45:00 -0800 (PST) Received: from localhost ([127.0.0.1]:50188 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1LFCFM-0002XX-LB; Tue, 23 Dec 2008 19:44:48 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Tue, 23 Dec 2008 18:44:48 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/17#comment:1 Message-ID: <066.2baf39015afe7bd9739af49dfd117183@tools.ietf.org> References: <057.f52fd136593ae14a05d8d1e25a6f62a7@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <057.f52fd136593ae14a05d8d1e25a6f62a7@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #17: WG last call on draft-ietf-dhc-relay-id-suboption X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #17: WG last call on draft-ietf-dhc-relay-id-suboption --------------------------------+------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: relay-id-suboption | Version: Severity: In WG Last Call | Resolution: Keywords: | --------------------------------+------------------------------------------- Old description: > The WG last call on draft-ietf-dhc-relay-id-suboption will end at 1700PDT > 12/19/08 > > The discussion thread for this WG last call is at www.ietf.org/mail- > archive/web/dhcwg/current/msg09266.html New description: The WG last call on draft-ietf-dhc-relay-id-suboption will end at 1700PDT 12/19/08 The discussion thread for this WG last call is at www.ietf.org/mail- archive/web/dhcwg/current/msg09266.html A reminder thread is at: http://www.ietf.org/mail- archive/web/dhcwg/current/msg09329.html -- Comment(by rdroms@cisco.com): From: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09297.html Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-relay-id- suboption-04.txt[[BR]] From: "Bernie Volz (volz)" [[BR]] Date: Tue, 9 Dec 2008 21:54:32 -0500 I support this draft moving forward "as is". - Bernie -----[[BR]] From: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09334.html Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay- id-suboption-04.txt[[BR]] From: "David W. Hankins" [[BR]] Date: Tue, 16 Dec 2008 13:03:09 -0800 On Tue, Dec 16, 2008 at 05:51:55AM -0500, Ralph Droms wrote:[[BR]] > http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id- suboption-04.txt I support the draft moving forward, just a minor wording thing; The type code zero is referred to as being reserved and MUST NOT be used, but the IANA considerations section seems to allocate this code to be named '_NULL'. I'd rather see this named _RESERVED, or placed in a 'reserved range', as that seems less confusing; 0 Reserved[[BR]] 1 RELAY_IDENTIFIER...etc I think the draft can move forward with or without any attempt to address this. -----[[BR]] From: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09361.html Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay- id-suboption-04.txt[[BR]] From: Kim Kinnear [[BR]] Date: Wed, 17 Dec 2008 17:08:05 -0500 (See http://trac.tools.ietf.org/wg/dhc/trac/ticket/20 for this issue) I have performed a detailed review of this document as I agreed to do when we met in Minneapolis. Since this was just re-issued as an -05.txt version, I reviewed the -05.txt version. It is acceptable as it is, and the several comments that I make below aren't intended to hold up the document's progress. If we can get some of these points addressed during some of the editing passes that are ahead, that would be nice but not required. Followup from: http://www.ietf.org/mail- archive/web/dhcwg/current/msg09340.html On Tue, Dec 16, 2008 at 04:41:11PM -0500, Mark Stapp wrote:[[BR]] > I've posted a new version of the relay-id suboption draft today.[[BR]] > The only change was to the IANA considerations section, as suggested by[[BR]] > David Hankins, to clarify the 'reserved' value. That's perfect, thank you Mark. ----- From: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09345.html Subject: Re: [dhcwg] REMINDER: dhc WG last call on draft-ietf-dhc-relay- id-suboption-04.txt[[BR]] From: Bharat Joshi [[BR]] Date: Wed, 17 Dec 2008 09:29:04 +0530 I have read this document and support to move it to next level. Thanks,[[BR]] Bharat -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 10:47:08 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB323A67D0; Tue, 23 Dec 2008 10:47:07 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0833A67D0 for ; Tue, 23 Dec 2008 10:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3G0CSd8YwPs for ; Tue, 23 Dec 2008 10:47:06 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id EC2213A67A1 for ; Tue, 23 Dec 2008 10:47:05 -0800 (PST) Received: from localhost ([127.0.0.1]:55397 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1LFCHN-0002iA-Hh; Tue, 23 Dec 2008 19:46:53 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: mjs@cisco.com, rdroms@cisco.com X-Trac-Project: dhc Date: Tue, 23 Dec 2008 18:46:53 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/20 Message-ID: <057.657542674b48c1dd8e82eab6db7f9a4f@tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mjs@cisco.com, rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: [dhcwg] [dhc] #20: Non-blocking comments on relay-id-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #20: Non-blocking comments on relay-id-option --------------------------------+------------------------------------------- Reporter: rdroms@cisco.com | Owner: mjs@cisco.com Type: defect | Status: new Priority: minor | Milestone: Component: relay-id-suboption | Version: Severity: In WG Last Call | Keywords: --------------------------------+------------------------------------------- See http://www.ietf.org/mail-archive/web/dhcwg/current/msg09361.html for the details of this issue -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 11:01:27 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149153A6B31; Tue, 23 Dec 2008 11:01:27 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53323A6B2B for ; Tue, 23 Dec 2008 11:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7Ox6+wTZFj7 for ; Tue, 23 Dec 2008 11:01:25 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 426AB28C169 for ; Tue, 23 Dec 2008 11:01:03 -0800 (PST) Received: from localhost ([127.0.0.1]:49436 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1LFCUt-0003I7-Ut; Tue, 23 Dec 2008 20:00:51 +0100 MIME-Version: 1.0 From: "dhc issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: rdroms@cisco.com X-Trac-Project: dhc Date: Tue, 23 Dec 2008 19:00:51 -0000 X-URL: http://tools.ietf.org/wg/dhc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/15#comment:3 Message-ID: <066.4cc91886bdaa136ac30bc34ff59daccd@tools.ietf.org> References: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.85744f873e81ed5e5e2ee73fdd94a476@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: dhcwg@ietf.org Subject: Re: [dhcwg] [dhc] #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dhcwg@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org #15: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: vpn-option | Version: Severity: In WG Last Call | Resolution: Keywords: | ------------------------------+--------------------------------------------- Comment(by rdroms@cisco.com): -----[[BR]] I just discovered two additional reviews... -----[[BR]] From: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09383.html Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09[[BR]] From: "Neil Russell (nrussell)" [[BR]] Date: Fri, 19 Dec 2008 11:58:55 -0500 I have read the draft and believe that it should move forward in the standards process. --N -----[[BR]] From: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09384.html Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09[[BR]] From: Josh Littlefield [[BR]] Date: Fri, 19 Dec 2008 14:35:37 -0500 I have reviewed the referenced draft (draft-ietf-dhc-vpn-option-09.txt) and fully support it's publication. I have submitted very minor editorial comments (missing or extra words) to the authors for correction during the final editing process. -josh -- Ticket URL: dhc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 11:12:18 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAF43A6856; Tue, 23 Dec 2008 11:12:18 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B393A6859 for ; Tue, 23 Dec 2008 11:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro93yFKtFtul for ; Tue, 23 Dec 2008 11:12:17 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AD8FF3A67DA for ; Tue, 23 Dec 2008 11:12:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,273,1228089600"; d="scan'208";a="31958600" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Dec 2008 19:12:08 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBNJC83P000802; Tue, 23 Dec 2008 14:12:08 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBNJC8I7012467; Tue, 23 Dec 2008 19:12:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 14:12:08 -0500 Received: from [161.44.65.106] ([161.44.65.106]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 14:12:07 -0500 Message-Id: <8E8C1C47-AC73-498A-A24A-EBD149570D31@cisco.com> From: Ralph Droms To: dhcwg@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 14:12:07 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Dec 2008 19:12:07.0881 (UTC) FILETIME=[595D0B90:01C96532] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=321; t=1230059528; x=1230923528; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Four=20drafts=20accepted=20as=20WG=20work=20ite ms. |Sender:=20 |To:=20dhcwg@ietf.org; bh=YMSXF+xwBN+6n3LtVOCCTEJWqYB/JW+sIk2V8tHILCM=; b=C+Xxt2VsyITzUbexDG8scE+X4jT6d9CV+rluFZgvhTJ88wdknCSV/tVsNh Kwbgb0IWPsCKrVMAlNCyZbY6eP94jR48dL8atub+XjNFeTTeXSmtEF4JOLnB zHeSl0VLAF; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: John Jason Brzozowski Subject: [dhcwg] Four drafts accepted as WG work items. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org There were no objections to accepting these drafts as WG work items: draft-volz-dhc-dhcpv4-vendor-message-00 draft-volz-dhc-dhcpv6-vendor-message-01 draft-kinnear-dhc-dhcpv4-bulk-leasequery-01 draft-dhankins-dhcpinform-clarify-00 Authors - please publish new revs of these drafts as draft-ietf-dhc-* - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 12:11:03 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001E63A6B35; Tue, 23 Dec 2008 12:11:02 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A2E3A6B35 for ; Tue, 23 Dec 2008 12:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK62o8xmEl5M for ; Tue, 23 Dec 2008 12:11:00 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 94DDA3A6B25 for ; Tue, 23 Dec 2008 12:11:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,273,1228089600"; d="scan'208";a="118181975" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 23 Dec 2008 20:10:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBNKAqks001465 for ; Tue, 23 Dec 2008 12:10:52 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBNKApC6020812 for ; Tue, 23 Dec 2008 20:10:51 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 15:10:51 -0500 Received: from [161.44.65.106] ([161.44.65.106]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 15:10:50 -0500 Message-Id: <95277F7C-730E-4265-869D-64ACDDE87782@cisco.com> From: Ralph Droms To: dhcwg@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 15:10:51 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Dec 2008 20:10:50.0906 (UTC) FILETIME=[8D3FFFA0:01C9653A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=237; t=1230063052; x=1230927052; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Option=20syntax=20in=20draft-ietf-mos-dhcp-opti ons |Sender:=20; bh=HPPe1i95632clo6FqKTRbE4DFV28BxldLMTROn59Lxw=; b=Hvm9UrIRfxYCWmoDSx7KjaPzD/ljeEUMCN/gsN7CsCTvgU3SHs+QlXoRye NuuEEckkrk5nHAmgTWWDmQudiwt0NE7MhNttprO5rZ2RcCbITxJ4yLmnzYg8 d2u4sF4X0EzXGYV1xGiX46Vd9A/LFJEbNxzRhzFLtc21CXGOqzyXc=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [dhcwg] Option syntax in draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I'd like to get WG feedback on draft-ietf-mos-dhcp-options, especially the option syntax in sections 2 and 3. How does this syntax align with the guidelines in David Hankins draft, and with implementation practice? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Dec 23 14:19:38 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD79728C18D; Tue, 23 Dec 2008 14:19:38 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F8D28C18C for ; Tue, 23 Dec 2008 14:19:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ3dzBVOn7uD for ; Tue, 23 Dec 2008 14:19:36 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 73ACB28C180 for ; Tue, 23 Dec 2008 14:19:36 -0800 (PST) Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id mBNMJPbm025378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Dec 2008 14:19:26 -0800 Received: by hcf.isc.org (Postfix, from userid 10200) id 5DEC55733E; Tue, 23 Dec 2008 14:20:42 -0800 (PST) Date: Tue, 23 Dec 2008 14:20:42 -0800 From: "David W. Hankins" To: DHC WG Message-ID: <20081223222041.GC3203@isc.org> References: <95277F7C-730E-4265-869D-64ACDDE87782@cisco.com> MIME-Version: 1.0 In-Reply-To: <95277F7C-730E-4265-869D-64ACDDE87782@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [dhcwg] Option syntax in draft-ietf-mos-dhcp-options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1508883670==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1508883670== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCKi3GIZzVBPywwA" Content-Disposition: inline --zCKi3GIZzVBPywwA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 23, 2008 at 03:10:51PM -0500, Ralph Droms wrote: > I'd like to get WG feedback on draft-ietf-mos-dhcp-options, especially th= e=20 I think you mean s/mos/mipshop-mos/? > option syntax in sections 2 and 3. How does this syntax align with the= =20 > guidelines in David Hankins draft, and with implementation practice? Wow. I'm not really sure where to start. It looks like the lemma I summarize as "conditional formatting is hard" is the one that needs to be reasserted here. These 'encoding octets' sound like a great idea, but in practice their inclusion means these sub-options are not going to be adopted by the existing DHCP network. It requires code changes, and I'm not convinced these configuration parameters are a big enough draw either for a sysadmin to upgrade his software, nor for a software manufacturer to write new code to support it specifically. I don't know a lot about MIP or MOS or ES or CS or IS or any of it, I admit. But the case hasn't been made for me to understand why the FQDN format has been included at all. It seems at first inspection as though the only benefit of the FQDN format in its NAPTR->SRV->A dereferencing is that it also carries DNS-based load balancing / management and port numbers. Well, DHCP servers can provide the same kind of load balancing by giving out different answers to different clients (if you like, I can show how we did this trivially as recently as IETF Philadelphia). If you want to include port numbers, then just switch to a 6-octet sized array (IP-address plus port number, compound arrayed). Existing software supports this, no upgrades necessary. Which brings me to the 7 sub-options being used here. This can also be written as (2^3)-1, which makes more sense when you realize that these 7 options are designed to convey all combinations of including IS, ES, and CS feature sets (2^3), minus the one combination that includes none of them. This is a scaling problem. If more feature sets are later defined, then you will need an exponential increase in option codes. This results in an exponential increase in written lines of code that surely will have to deal with the situations that arise when conflicting configuration is present in multiple suboptions. It is further limited to just 7 sets of feature sets; 2^8-1 is 255, which may be treated by some older software as an END option, even in a sub-option space that has no such definition. It seems to me it would be better to define just three sub-options, and if any server fulfilled multiple roles, list them in each option. In essence, if a client were looking for a particular role, it would use the list specific to that service it is soliciting. As a minor note, I'd suggest calling the suboption numerical assignments "codes" and not "types." Maybe it's just me, but it seems that we refer to DHCP "code and length octets" comprising DHCP options and suboptions. --=20 Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --zCKi3GIZzVBPywwA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklRZDkACgkQcXeLeWu2vmpGZwCfdsV9GxOLkup53C4ShBZpawtl 82UAnj8JIW5IdLu48cg5+BEQbgNOTN8c =O6mI -----END PGP SIGNATURE----- --zCKi3GIZzVBPywwA-- --===============1508883670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============1508883670==-- From dhcwg-bounces@ietf.org Wed Dec 24 04:14:08 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BE328C146; Wed, 24 Dec 2008 04:14:08 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3033A6B52; Wed, 24 Dec 2008 04:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6NqWACSQ+B1; Wed, 24 Dec 2008 04:14:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0C64D3A67E1; Wed, 24 Dec 2008 04:14:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,278,1228089600"; d="scan'208";a="31984297" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Dec 2008 12:13:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBOCDopx031062; Wed, 24 Dec 2008 07:13:50 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBOCDn4r020736; Wed, 24 Dec 2008 12:13:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 07:11:29 -0500 Received: from bxb-rdroms-8717.cisco.com ([10.98.10.88]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 07:11:28 -0500 Message-Id: From: Ralph Droms To: "James M. Polk" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 24 Dec 2008 07:11:27 -0500 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Dec 2008 12:11:28.0363 (UTC) FILETIME=[BFD9FBB0:01C965C0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8772; t=1230120830; x=1230984830; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20FW=3A=20I-D=20Action=3Adraft- ietf-geopriv-dhcp-lbyr-uri-option-03.txt |Sender:=20 |To:=20=22James=20M.=20Polk=22=20; bh=5LLQu8D8mwJckhP9gZxCmOLjLvnlj8bmRbPGIlnP1RA=; b=sENSow+OBgezZM6ViDncxVwWMHVTitKLSh1byqV8AXM8chueZEpum1bqOx QiNx5Xu+KppM6S/z8GkU1yNvOlDqQDQcZZHoNEtJ7sCCmbpOJj4kT6j2kDAl OlrdQZPF6e; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: geopriv@ietf.org, DHC-WG WG Subject: Re: [dhcwg] FW: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here's my review of this draft. Additional reviews welcome... Is there a reason not to define a DHCPv6 version of this option in the same document? Seems to me the syntax and semantics would be identical for IPv4 and IPv6; all that would be needed would be another section defining the DHCPv6 option syntax. From section 2.1: The field indicates how long, in seconds, the client is to consider this Location-URI valid before performing a refresh of this Option, with a refreshed value. A refresh MAY be done merely at the normal DHCP refresh rate, or necessitated by this timer, perhaps with the client just requesting this Option be refreshed. What is a "refresh of this option"? I thought the idea is to hand out a permanent URI through which other devices can determine the location of the DHCP client host. Under what circumstances would the URI change, esp. without the DHCP lease requiring a renewal? It might be clearer to explain that "the client just requesting this Option be refreshed" would likely be implemented through a DHCPINFORM/DHCPACK message exchange. Following paragraph: It is RECOMMENDED when the counter associated with this value has passed, the client perform a refresh of this Option. For example, if 600 was the initial value of the field, when 300 seconds have passed, the Option SHOULD be refreshed. I think there might be some text missing in this paragraph referring to 1/2 of the value? First paragraph of section 3: The [RFC3046] RAIO MUST be utilized to provide the appropriate indication to the DHCP Server where this DISCOVER or REQUEST message came from, in order to supply the correct response. That said, this Option SHOULD NOT be in a DISCOVER message, because there is zero knowledge by the client of which Server will answer. I infer that any one of the RAIO sub-options that can be used to determine a client's location would be appropriate here? Is an RAIO the only way in which the DHCP server can determine the client's location? I don't understand the last sentence and the importance of "zero knowledge by the client of which Server will answer." Later in section 3: In the case of residential gateways being DHCP servers, they usually perform as DHCP clients in a hierarchical fashion up into a service provider's network DHCP server(s), or learn what information to provide via DHCP to residential clients through a protocol such as PPP. In these cases, the Location-URI would likely indicate the residence's civic address to all wired or wireless clients within that residence. This is not inconsistent with what's stated above. I think the implication here is that the residential gateway will pass this option to any devices in the residential network. If I have that right, it might improve clarity to state that expectation explicitly. - Ralph On Dec 9, 2008, at 6:20 AM, Ralph Droms wrote: > Here's another draft the WG should review. I need to find a least > one volunteer to read the DHCP-related portions of this draft and > publish comments. > > - Ralph > > >>>> ------ Forwarded Message >>>> From: >>>> Reply-To: >>>> Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) >>>> To: >>>> Cc: >>>> Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Geographic Location/Privacy >>>> Working >>>> Group >>>> of the IETF. >>>> >>>> >>>> Title : Dynamic Host Configuration Protocol (DHCP) Option >>>> for a >>>> Location Uniform Resource Identifier (URI) >>>> Author(s) : J. Polk >>>> Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>> Pages : 11 >>>> Date : 2008-11-03 >>>> >>>> This document creates a Dynamic Host Configuration Protocol (DHCP) >>>> Option for the downloading of a Uniform Resource Identifier (URI) >>>> pointing to the geolocation record of an endpoint. This URI, >>>> called >>>> a Location-by-Reference (LbyR), points to a record on a location >>>> server which tracks the geolocation of the endpoint. Once >>>> downloaded by an endpoint, this LbyR can be forwarded to another >>>> entity, to be dereferenced if this entity wants to learn the >>>> geolocation of the sender endpoint. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- >>>> 03.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. >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> ------ End of Forwarded Message >>> >>> >>> >>> James - I can't recall if your draft has been discussed in the dhc >>> WG; I don't think it has. Depending on its current state, it >>> would be a good idea to get a quick review now, as the WG will >>> likely be asked to review it during any last calls. >>> >>> - Ralph >>> >>> Begin forwarded message: >>> >>>> From: "Ralph Droms (rdroms)" <rdroms@cisco.com >>>> > >>>> Date: November 3, 2008 8:16:49 PM EST >>>> To: "DHC WG" <dhcwg@ietf.org> >>>> Subject: [dhcwg] FW: I-DAction:draft-ietf-geopriv-dhcp-lbyr-uri- >>>> option-03.txt >>>> >>>> Here's another draft the WG should review. >>>> >>>> - Ralph >>>> ------ Forwarded Message >>>> From: <Internet-Drafts@ietf.org> >>>> Reply-To: <internet-drafts@ietf.org >>>> > >>>> Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) >>>> To: <i-d-announce@ietf.org> >>>> Cc: <geopriv@ietf.org> >>>> Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Geographic Location/Privacy >>>> Working Group >>>> of the IETF. >>>> >>>> >>>> Title : Dynamic Host Configuration Protocol (DHCP) >>>> Option for a >>>> Location Uniform Resource Identifier (URI) >>>> Author(s) : J. Polk >>>> Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>> Pages : 11 >>>> Date : 2008-11-03 >>>> >>>> This document creates a Dynamic Host Configuration Protocol (DHCP) >>>> Option for the downloading of a Uniform Resource Identifier (URI) >>>> pointing to the geolocation record of an endpoint. This URI, >>>> called >>>> a Location-by-Reference (LbyR), points to a record on a location >>>> server which tracks the geolocation of the endpoint. Once >>>> downloaded by an endpoint, this LbyR can be forwarded to another >>>> entity, to be dereferenced if this entity wants to learn the >>>> geolocation of the sender endpoint. >>>> >>>> A URL for this Internet-Draft is: >>>> >>> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- >>>> 03.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. >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> ------ End of Forwarded Message >>> >>> >> > > _______________________________________________ > 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 dhcwg-bounces@ietf.org Wed Dec 24 04:24:30 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11353A6B64; Wed, 24 Dec 2008 04:24:30 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9BC3A6B64 for ; Wed, 24 Dec 2008 04:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uoPgUh8ifYI for ; Wed, 24 Dec 2008 04:24:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0F85F3A6B6A for ; Wed, 24 Dec 2008 04:24:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,278,1228089600"; d="scan'208";a="31984898" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Dec 2008 12:24:18 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBOCOIcB023467; Wed, 24 Dec 2008 07:24:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBOCOIYv009093; Wed, 24 Dec 2008 12:24:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 07:24:18 -0500 Received: from bxb-rdroms-8717.cisco.com ([10.98.10.88]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 07:24:17 -0500 Message-Id: <2D21FDF6-7BF2-4051-BAA0-442177603393@cisco.com> From: Ralph Droms To: Bernie Volz (volz) In-Reply-To: <8E296595B6471A4689555D5D725EBB2109E4323F@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 24 Dec 2008 07:24:16 -0500 References: <4935915E.1060708@Dartmouth.edu><493D5B77.1050708@Dartmouth.edu><52028AF8-6F1E-430A-8A52-19ECEE1ADDD6@cisco.com> <493D9D81.4090301@Dartmouth.edu> <8E296595B6471A4689555D5D725EBB2109E4323F@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Dec 2008 12:24:18.0067 (UTC) FILETIME=[8AA17E30:01C965C2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2993; t=1230121458; x=1230985458; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20PKIX=20WG=20new=20I-D=20draft =3A=20DHCP=20section=20review |Sender:=20 |To:=20Bernie=20Volz=20(volz)=20; bh=/oQIOMyVK2yZTGb7ZgHkq4JTBZFrnlZFe0t0P9dLxGI=; b=nR7DmDYk40a7I+lNV7WRrRlwXejxw0lDMUiQOkmio2ZV8yuIrzFnehZ4xZ hItktc+VPO/rMHY+OQpbOLyepxmK92A14FwM/bRu4KlSJejef8kMRiKo6P7d fEj3rH/ynD; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: DHC-WG WG , Massimiliano Pala , Damien Neil Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie - thanks for your review; responses in line... - Ralph On Dec 9, 2008, at 10:05 PM, Bernie Volz (volz) wrote: > While the DHCP(v4+v6) option definitions are now much better (in > 02), I > wonder whether this will fly. > > Can new options be defined in an Appendix of an RFC? Good questions. RFC 2939 does not preclude the definition of new options in an Appendix. Neither does RFC 2939 preclude the definition of new options in an Experimental RFC. > There's no IANA directives in the draft to request IANA to assign > codes > for these options? In fact: > > 5. IANA Considerations > > This document has no actions for IANA. > > Which is clearly wrong if new DHCP options are to be assigned? Correct. This text needs to be changed. > Also, while DHCPv6 has plenty of "available" option numbers, DHCPv4 > doesn't have as many. I wonder whether if this is truly experimental, > that a Vendor Specific Information Option (for both v4 + v6) might not > be better? You would need to get an Enterprise-ID if you don't already > have one. If all depends on how widely this is to be implemented (ie, > how experimental is it?). > > If 'real' IANA assigned options are desired, the Appendix/IANA > cosniderations issues are more likely for the AD to address? Or you > might want to see what other Experimental RFCs have done in terms of > new > definitions for IANA maintained registries. As a practical matter, pressure on the DHCPv4 option code space has been reduced with the expansion of the list of available options and a slowdown in the rate of defining new options. I don't think assigning a DHCPv4 option code for this option is problematic. I agree that the Vendor-identifying Vendor Specific Option might be a good way to finesse the problem. > - Bernie - Ralph > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Massimiliano Pala > Sent: Monday, December 08, 2008 5:20 PM > To: Ralph Droms (rdroms) > Cc: DHC-WG; Damien Neil > Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review > > Hi Ralph, > > that was kinda not clear to me - I thought that I did not need to > define > two different options for DHCPv4 and DHCPv6. I just uploaded the new > version > of the draft where I defined the PRQP server option for DHCPv4 and > DHCPv6. > > The new draft is published as: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-02.txt > > Please let me know what you think of this new version and if I > successfully > addressed your concerns :D > > Cheers, > Max > > Ralph Droms wrote: >> You could choose either IP addresses or FQDNs for the option payload. > >> But, you'll still have to define both DHCPv4 and DHCPv6 versions of > the >> option. >> >> You might want to look at >> > http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03 > . > txt > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 24 07:36:29 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0BD3A67DF; Wed, 24 Dec 2008 07:36:29 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0BB3A67C0 for ; Wed, 24 Dec 2008 07:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XENMAFduoj0 for ; Wed, 24 Dec 2008 07:36:26 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 358233A67DF for ; Wed, 24 Dec 2008 07:36:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,279,1228089600"; d="scan'208";a="32033541" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Dec 2008 15:36:16 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBOFaGvW031171 for ; Wed, 24 Dec 2008 10:36:16 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBOFaGcv021566 for ; Wed, 24 Dec 2008 15:36:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 10:36:16 -0500 Received: from bxb-rdroms-8717.cisco.com ([10.98.10.88]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 10:36:16 -0500 Message-Id: From: Ralph Droms To: Dhcwg WG In-Reply-To: <1DBEF0D3-DBDF-4787-87DB-511B133DA949@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 24 Dec 2008 10:36:16 -0500 References: <1DBEF0D3-DBDF-4787-87DB-511B133DA949@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Dec 2008 15:36:16.0557 (UTC) FILETIME=[5C2F95D0:01C965DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2110; t=1230132976; x=1230996976; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20*SECOND=20TRY*=20Re=3A=20Review=20of=20draft-ie tf-netlmm-pmip6-ipv4-support |Sender:=20 |To:=20Dhcwg=20WG=20; bh=a5rNeF2G+9xuSKAZi2rS7yDYrWMijrWDvAZVZ49QCHs=; b=Xfd0kmvw1VVJSug+i5DwhbFXvlWjl5rle6sZ8Ug9IQ1UTpLlTOnv31ULSz FEtl+0vVEZdpHMd2uZUbEYyPLltT2p8yCNQuZPQVUJocToCcC+LbQ8RGHNKX eqIcCpQ8G0; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [dhcwg] *SECOND TRY* Re: Review of draft-ietf-netlmm-pmip6-ipv4-support X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org draft-ietf-netlmm-pmip6-ipv4-support-07.txt was just published; reviews solicited. - Ralph On Dec 5, 2008, at 6:50 AM, Ralph Droms wrote: > I'd like to get dhc WG review of draft-ietf-netlmm-pmip6-ipv4- > support (details below). I'm especially interested in taking a > close look at mobile node identification to the DHCP service and the > ways in which multiple DHCP servers may have to be coordinated for > mobile nodes using IPv4 and DHCP. > > Please cross-post any responses to netlmm@ietf.org > > Thanks... > > - Ralph > > ===== > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network-based Localized Mobility > Management Working Group of the IETF. > > > Title : IPv4 Support for Proxy Mobile IPv6 > Author(s) : R. Wakikawa, S. Gundavelli > Filename : draft-ietf-netlmm-pmip6-ipv4-support-06.txt > Pages : 49 > Date : 2008-11-27 > > This document specifies extensions to Proxy Mobile IPv6 protocol for > adding IPv4 protocol support. The scope of IPv4 protocol support is > two-fold: 1) enable IPv4 home address mobility support to the mobile > node. 2) allowing the mobility entities in the Proxy Mobile IPv6 > domain to exchange signaling messages over an IPv4 transport network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-06.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. > Content-Type: text/plain
Content-ID: <2008-11-27200120.I-D@ietf.org > >

_______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Dec 24 08:01:36 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8993A67F9; Wed, 24 Dec 2008 08:01:36 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FEA3A69D8 for ; Tue, 23 Dec 2008 13:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.509 X-Spam-Level: * X-Spam-Status: No, score=1.509 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zpTHc+t-LuJ for ; Tue, 23 Dec 2008 13:04:26 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 735A03A68B6 for ; Tue, 23 Dec 2008 13:04:25 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA087606159; Tue, 23 Dec 2008 22:02:39 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA15459; Tue, 23 Dec 2008 22:02:38 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200812232102.WAA15459@TR-Sys.de> To: raj@cisco.com, mjs@cisco.com, jayk@cisco.com Date: Tue, 23 Dec 2008 22:02:38 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 X-Mailman-Approved-At: Wed, 24 Dec 2008 08:01:35 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-vpn-option-09 issue with sub-option bouncing X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org SSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtZGhjLXZwbi1vcHRpb24tMDkgYW5kIGFscmVhZHkg c2VudApvZmYtbGlzdCBhIGNvdXBsZSBvZiBlZGl0b3JpYWwgbm90ZXMuCgpIb3dldmVyLCBJIHNl ZSBvbmUgc2lnbmlmaWNhbnQgaXNzdWUgbm90IHNhdGlzZmFjdG9yaWx5IHJlc29sdmVkCmluIHRo ZSBjdXJyZW50IGRyYWZ0IHZlcnNpb24uCkJlbG93LCBJIHJlY2FsbCB0aGUgcHJvYmxlbSBhbmQg cHJvcG9zZSBhIG1lY2hhbmlzbSB0byBtaXRpZ2F0ZSBpdC4KCkFzIGV4cGxhaW5lZCBpbiB2YXJp b3VzIHBsYWNlcyBpbiB0aGUgZHJhZnQgKGluIHBhcnRpY3VsYXIKU2VjdGlvbiA3LjIpLCBpbiB0 aGUgREhQQ3Y0IGNhc2UgdGhlIHV0aWxpdHkgb2YgdGhlIFZTUyBzdWItb3B0aW9uCnN1ZmZlcnMg ZnJvbSB0aGUgZGVmYXVsdCBiZWhhdmlvciBvZiB0aGUgc2VydmVyIChwZXIgUkZDIDMwNDYpIG9m CmJsaW5kbHkgYm91bmNpbmcgdW5rbm93biBzdWItb3B0aW9ucyBvZiB0aGUgUmVhbHktQWdlbnQt SW5mb3JtYXRpb24Kb3B0aW9uLiAgVGhpcyB3YXksIHRoZSBESENQIHJlbGF5IG9yaWdpbmFsbHkg c2VuZGluZyB0aGUgc3ViLW9wdGlvbgppbiB0aGUgcmVxdWVzdCBjYW4gbm90IGNvbmNsdWRlIGZy b20gdGhlIHN1Yi1vcHRpb24gaW4gdGhlIHJlcGx5CndoZXRoZXIgdGhlIHNlcnZlciBoYXMgbm90 IHVuZGVyc3Rvb2QgdGhlIFZTUyBzdWItb3B0aW9uIGFuZCBzaW1wbHkKYm91bmNlZCBpdCBvciBp dCBoYXMgdW5kZXJzdG9vZCB0aGUgVlNTIHN1Yi1vcHRpb24gYW5kIGNvbmZpcm1lZAp0aGUgdmFs dWUgc2VudCBpbiB0aGUgcmVxdWVzdCBieSBlY2hvaW5nIHRoZSB1bmNoYW5nZWQgVlNTIHN1Yi0K b3B0aW9uLgoKVGhhdCBzZWVtcyB0byBiZSBhIHNpZ25pZmljYW50IGRyYXdiYWNrLgoKQWZ0ZXIg c29tZSBjb25zaWRlcmF0aW9uIG9mIHRoZSBwcm9ibGVtLCBpdCBiZWNvbWVzIGFwcGFyZW50IHRo YXQKaXQgZGVwZW5kcyBvbiB0aGUgVlNTIHR5cGUgd2hldGhlciBvciBub3QgdGhpcyBpcyBhIHJl YWwgaXNzdWUuCkluIHRoZSAiZ2xvYmFsL2RlZmF1bHQgVlBOIiBjYXNlIChWU1MgdHlwZSAyNTUp LCBpdCBsb29rcyBsaWtlCnRoZSByZWFseSBhZ2VudCB3b3VsZCBub3QgZ2FpbiBhbnl0aGluZyBm cm9tIGJlaW5nIGFibGUgdG8KZGlzdGluZ3Vpc2ggdGhlIHR3byBjYXNlczsgdGhhdCBhcHBhcmVu dGx5IG9ubHkgbWF0dGVycyBmb3IgdGhlClZTUyB0eXBlcyAwIGFuZCAxIChvciBhbnkgcG9zc2li bGUgZnV0dXJlICdjb25jcmV0ZScgdmFsdWVzKS4KClRoaXMgaGFzIGd1aWRlZCBtZSB0byBlbnZp c2lvbiBtb2RpZmllZCBlbmNvZGluZyBhbmQgcHJvY2Vzc2luZwpydWxlcyBvZiB0aGUgVlNTIHR5 cGUgLS0gc2VlIGJlbG93LgoKRHVlIHRvIGxhY2sgb2YgdGltZSwgSSBoYXZlIG5vdCB0cmllZCB0 byBkaXNjb3ZlciBpZiB0aGlzIGlkZWEKYWxyZWFkeSBoYXMgYmVlbiBjb25zaWRlcmVkIGluIHRo ZSBwYXN0LiAgSWYgc28sIGFuZCBpdCBoYXMgYmVlbgpyZWplY3RlZCwgSSBhcG9sb2dpemUgZm9y IGJyaW5naW5nIGl0IHVwIGFnYWluLgoKYSkgIEVuY29kaW5nOgoKICBWU1MgdHlwZXMgMTI3Li4y NTQgYXJlIHBlcm1hbmVudGx5IGZvcmJpZGRlbiBmb3IgVlNTIGluZm9ybWF0aW9uCiAgaW4gdGhl IERIVlB2NC92NiBWU1Mgb3B0aW9ucyBhbmQgdGhlIHY0IFZTUyBzdWItb3B0aW9uIGluIGEKICBt ZXNzYWdlIHRvIHRoZSBzZXJ2ZXIuCgogIEZvciB0aGUgVlNTIHN1Yi1vcHRpb24gaW4gYSByZXNw b25zZSwgdGhlIGZvbGxvd2luZyBhZGRpdGlvbmFsCiAgdmFsdWVzIGFyZSBkZWZpbmVkOgoKICAg ICAgMTI4ICAgc2FtZSBhcyAwLCBidXQgImNvbmZpcm1lZCBieSBzZXJ2ZXIiCiAgICAgIDEyOSAg IHNhbWUgYXMgMSwgYnV0ICJjb25maXJtZWQgYnkgc2VydmVyIgoKYikgU2VydmVyIFByb2Nlc3Np bmcKCkEgREhDUHY0IHNlcnZlciB0aGF0IHVuZGVyc3RhbmRzIHRoZSBWU1Mgc3ViLW9wdGlvbiAo YW5kIHN1cHBvcnRzCnRoaXMgYWR2YW5jZWQgZW5jb2RpbmcpIHNldHMgdGhlIE1TQiBpbiB0aGUg VlNTIHR5cGUgd2hlbiBpdCBjb3BpZXMKdGhlIHN1Yi1vcHRpb24gdG8gdGhlIHJlc3BvbnNlICJ1 bmNoYW5nZWQiIHBlciB0aGUgY3VycmVudCBkcmFmdC4KTm90ZSB0aGF0IHRoaXMgaXMgYW4gaWRl bXBvdGVudCBvcGVyYXRpb24gb24gdGhlICdnbG9iYWwnIFZTUyB0eXBlCnZhbHVlLCBsZWF2aW5n IGl0IHVuY2hhbmdlZCBmb3IgaW1wcm92ZWQgaW50ZXJvcGVyYWJpbGl0eSB3aXRoCmV4aXN0aW5n IGltcGxlbWVudGF0aW9ucy4KClRCRDogSXQgbmVlZHMgdG8gYmUgZmlndXJlZCBvdXQgd2hldGhl ciBpdCBtaWdodCBiZSBwcmVmZXJhYmxlCiAgICAgKHlldCBsZXNzIGJhY2t3YXJkcyBjb21wYXRp YmxlKSB0byBhbHNvIHNldCB0aGUgTVNCIHdoZW4gdGhlCiAgICAgc2VydmVyICpjaGFuZ2VzKiB0 aGUgVlMgdHlwZSBpbiB0aGUgVlNTIHN1Yi1vcHRpb24gdG8gYmUgc2VudAogICAgIGJhY2sgdG8g b25lIG9mIHRoZSAnY29uY3JldGUnIHZhbHVlcyAoY3VycmVudGx5IDAgb3IgMSkuCgpOb3RlOiBU aGlzIHJldmlzZWQgc2VydmVyIGJlaGF2aW9yIFNIT1VMRCBiZSBzdWJqZWN0IHRvIGFjdGl2YXRp b24KICAgICAgcGVyIGNvbmZpZ3VyYXRpb24sIHdpdGggZGVmYXVsdHMgdG8gJ29mZicuCgpjKSBS ZWxheSBBZ2VudCBQcm9jZXNzaW5nCgpBIERIQ1B2NCBSZWxheSBBZ2VudCByZWNlaXZpbmcgb25l IG9mIHRoZSBuZXcgVlNTIHR5cGVzIGluIHRoZQpWU1Mgc3ViLW9wdGlvbiBzdHJpcHMgdGhlIE1T QiBvZiB0aGUgVlNTIHR5cGUgYW5kIHBlcmZvcm1zIHRoZQpwcm9jZXNzaW5nIGN1cnJlbnRseSBk ZXNjcmliZWQgaW4gdGhlIGRyYWZ0LCBidXQgaXQgYWxzbyBub3RlcyB0aGF0CnRoZSBzZXJ2ZXIg aGFzIGNvbmZpcm1lZCB0aGUgKHByb3Bvc2VkKSB2YWx1ZSBpdCBoYWQgc2VudCBpbiB0aGUKcmVx dWVzdCwgYW5kIGNhbiBoZW5jZSBleGNsdWRlIGFsbCBjb25zaWRlcmF0aW9ucyBhbmQgY2F1dGlv bmFyeQpwcm9jZXNzaW5nIHJlbGF0ZWQgdG8gbGFjayBvZiBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRo ZSB0d28gY2FzZXMuCgoKS2luZCByZWdhcmRzLAogIEFsZnJlZCBIzm5lcy4KCi0tIAoKKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKfCBUUi1TeXMgQWxmcmVkIEhvZW5lcyAgIHwgIEFsZnJlZCBIb2VuZXMgICBEaXBs Li1NYXRoLiwgRGlwbC4tUGh5cy4gIHwKfCBHZXJsaW5nZXIgU3RyYXNzZSAxMiAgIHwgIFBob25l OiAoKzQ5KTcxNTYvOTYzNS0wLCBGYXg6IC0xOCAgICAgICAgIHwKfCBELTcxMjU0ICBEaXR6aW5n ZW4gICAgIHwgIEUtTWFpbDogIGFoQFRSLVN5cy5kZSAgICAgICAgICAgICAgICAgICAgIHwKKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCg== From dhcwg-bounces@ietf.org Wed Dec 24 11:54:50 2008 Return-Path: X-Original-To: dhcwg-archive@megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73F428C0E0; Wed, 24 Dec 2008 11:54:50 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3E93A6A48; Wed, 24 Dec 2008 11:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am5VmR-Zu5Xu; Wed, 24 Dec 2008 11:54:48 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 31BA43A686A; Wed, 24 Dec 2008 11:54:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,279,1228089600"; d="scan'208";a="122544369" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 24 Dec 2008 19:54:39 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mBOJsd6e019462; Wed, 24 Dec 2008 11:54:39 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id mBOJsdvp004278; Wed, 24 Dec 2008 19:54:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 11:54:39 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.16.127]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 11:54:38 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Dec 2008 13:54:37 -0600 To: Ralph Droms From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 24 Dec 2008 19:54:38.0877 (UTC) FILETIME=[7449E4D0:01C96601] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9011; t=1230148479; x=1231012479; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dhcwg]=20FW=3A=20I-D=0A=20=20Action=3A draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt |Sender:=20; bh=iX5+H4IoH5HT6BXvN0M3HtoGfIjKx6yPOAlEIJ/t3qI=; b=DwA1bFCeyAn5YX8qujsd8ukbJju71D6tSaphibLimq7BNLcA5clyj+hP2f PNt+lTOrY8yVhrffWWPGf+MVK114aRsFsjW91R9kaUNyncR2fyooMcHhZsuc aWY1srOARI; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: geopriv@ietf.org, DHC-WG WG Subject: Re: [dhcwg] FW: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph Thanks for the review. I'll work on a response over the weekend and reply-all, for others awareness and comments. Happy Holidays! James At 06:11 AM 12/24/2008, Ralph Droms wrote: >Here's my review of this draft. Additional reviews welcome... > >Is there a reason not to define a DHCPv6 version of this option in the >same document? Seems to me the syntax and semantics would be >identical for IPv4 and IPv6; all that would be needed would be another >section defining the DHCPv6 option syntax. > > From section 2.1: > > The field indicates how long, in seconds, the client is > to consider this Location-URI valid before performing a refresh of > this Option, with a refreshed value. A refresh MAY be > done merely at the normal DHCP refresh rate, or necessitated by this > timer, perhaps with the client just requesting this Option be > refreshed. > >What is a "refresh of this option"? I thought the idea is to hand out >a permanent URI through which other devices can determine the location >of the DHCP client host. Under what circumstances would the URI >change, esp. without the DHCP lease requiring a renewal? It might be >clearer to explain that "the client just requesting this Option be >refreshed" would likely be implemented through a DHCPINFORM/DHCPACK >message exchange. > >Following paragraph: > > It is RECOMMENDED when the counter associated with this > value has passed, the client perform a refresh of this Option. For > example, if 600 was the initial value of the field, when > 300 seconds have passed, the Option SHOULD be refreshed. > >I think there might be some text missing in this paragraph referring >to 1/2 of the value? > >First paragraph of section 3: > > The [RFC3046] RAIO MUST be utilized to provide the appropriate > indication to the DHCP Server where this DISCOVER or REQUEST message > came from, in order to supply the correct response. That said, this > Option SHOULD NOT be in a DISCOVER message, because there is zero > knowledge by the client of which Server will answer. > >I infer that any one of the RAIO sub-options that can be used to >determine a client's location would be appropriate here? Is an RAIO >the only way in which the DHCP server can determine the client's >location? I don't understand the last sentence and the importance of >"zero knowledge by the client of which Server will answer." > >Later in section 3: > > In the case of residential gateways being DHCP servers, they usually > perform as DHCP clients in a hierarchical fashion up into a service > provider's network DHCP server(s), or learn what information to > provide via DHCP to residential clients through a protocol such as > PPP. In these cases, the Location-URI would likely indicate the > residence's civic address to all wired or wireless clients within > that residence. This is not inconsistent with what's stated above. > >I think the implication here is that the residential gateway will pass >this option to any devices in the residential network. If I have that >right, it might improve clarity to state that expectation explicitly. > >- Ralph > >On Dec 9, 2008, at 6:20 AM, Ralph Droms wrote: > >>Here's another draft the WG should review. I need to find a least >>one volunteer to read the DHCP-related portions of this draft and >>publish comments. >> >>- Ralph >> >> >>>>>------ Forwarded Message >>>>>From: >>>>>Reply-To: >>>>>Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) >>>>>To: >>>>>Cc: >>>>>Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. >>>>>This draft is a work item of the Geographic Location/Privacy >>>>>Working >>>>>Group >>>>>of the IETF. >>>>> >>>>> >>>>>Title : Dynamic Host Configuration Protocol (DHCP) Option >>>>>for a >>>>>Location Uniform Resource Identifier (URI) >>>>>Author(s) : J. Polk >>>>>Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>>>Pages : 11 >>>>>Date : 2008-11-03 >>>>> >>>>>This document creates a Dynamic Host Configuration Protocol (DHCP) >>>>>Option for the downloading of a Uniform Resource Identifier (URI) >>>>>pointing to the geolocation record of an endpoint. This URI, >>>>>called >>>>>a Location-by-Reference (LbyR), points to a record on a location >>>>>server which tracks the geolocation of the endpoint. Once >>>>>downloaded by an endpoint, this LbyR can be forwarded to another >>>>>entity, to be dereferenced if this entity wants to learn the >>>>>geolocation of the sender endpoint. >>>>> >>>>>A URL for this Internet-Draft is: >>>>>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- >>>>>03.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. >>>>>_______________________________________________ >>>>>I-D-Announce mailing list >>>>>I-D-Announce@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>>------ End of Forwarded Message >>>> >>>> >>>> >>>>James - I can't recall if your draft has been discussed in the dhc >>>>WG; I don't think it has. Depending on its current state, it >>>>would be a good idea to get a quick review now, as the WG will >>>>likely be asked to review it during any last calls. >>>> >>>>- Ralph >>>> >>>>Begin forwarded message: >>>> >>>>>From: "Ralph Droms (rdroms)" <rdroms@cisco.com > >>>>>Date: November 3, 2008 8:16:49 PM EST >>>>>To: "DHC WG" <dhcwg@ietf.org> >>>>>Subject: [dhcwg] FW: I-DAction:draft-ietf-geopriv-dhcp-lbyr-uri- >>>>>option-03.txt >>>>> >>>>>Here's another draft the WG should review. >>>>> >>>>>- Ralph >>>>>------ Forwarded Message >>>>>From: <Internet-Drafts@ietf.org> >>>>>Reply-To: <internet-drafts@ietf.org > >>>>>Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) >>>>>To: <i-d-announce@ietf.org> >>>>>Cc: <geopriv@ietf.org> >>>>>Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. >>>>>This draft is a work item of the Geographic Location/Privacy >>>>>Working Group >>>>>of the IETF. >>>>> >>>>> >>>>>Title : Dynamic Host Configuration Protocol (DHCP) >>>>>Option for a >>>>>Location Uniform Resource Identifier (URI) >>>>>Author(s) : J. Polk >>>>>Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt >>>>>Pages : 11 >>>>>Date : 2008-11-03 >>>>> >>>>>This document creates a Dynamic Host Configuration Protocol (DHCP) >>>>>Option for the downloading of a Uniform Resource Identifier (URI) >>>>>pointing to the geolocation record of an endpoint. This URI, >>>>>called >>>>>a Location-by-Reference (LbyR), points to a record on a location >>>>>server which tracks the geolocation of the endpoint. Once >>>>>downloaded by an endpoint, this LbyR can be forwarded to another >>>>>entity, to be dereferenced if this entity wants to learn the >>>>>geolocation of the sender endpoint. >>>>> >>>>>A URL for this Internet-Draft is: >>>>>>>>> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- >>>>>03.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. >>>>>_______________________________________________ >>>>>I-D-Announce mailing list >>>>>I-D-Announce@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>Internet-Draft directories: >>>>>http://www.ietf.org/shadow.html >>>>>or >>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>>------ End of Forwarded Message >>>> >> >>_______________________________________________ >>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 mail@1jian.com Fri Dec 26 18:09:53 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8203A6A56 for ; Fri, 26 Dec 2008 18:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -48.43 X-Spam-Level: X-Spam-Status: No, score=-48.43 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dYMtxOdAKWg for ; Fri, 26 Dec 2008 18:09:52 -0800 (PST) Received: from ppp-58-10-207-240.revip2.asianet.co.th (ppp-58-10-207-240.revip2.asianet.co.th [58.10.207.240]) by core3.amsl.com (Postfix) with SMTP id 5CB093A6A5A for ; Fri, 26 Dec 2008 18:09:50 -0800 (PST) To: Subject: Returned mail: Over quota From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227020951.5CB093A6A5A@core3.amsl.com> Date: Fri, 26 Dec 2008 18:09:50 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From julian.apaicio@advantech.de Fri Dec 26 23:47:13 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5E83A6833 for ; Fri, 26 Dec 2008 23:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.385 X-Spam-Level: X-Spam-Status: No, score=-18.385 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_DSL_3=1.022, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhR4VsAfbxPg for ; Fri, 26 Dec 2008 23:47:12 -0800 (PST) Received: from dsl-67-55-1-67.acanac.net (dsl-67-55-1-67.acanac.net [67.55.1.67]) by core3.amsl.com (Postfix) with SMTP id 9B98C3A6407 for ; Fri, 26 Dec 2008 23:47:11 -0800 (PST) To: Subject: We are aimed at promoting your health From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227074711.9B98C3A6407@core3.amsl.com> Date: Fri, 26 Dec 2008 23:47:11 -0800 (PST)

If you are unable to see the message below, click here to view.

The earlier you start treatment, the sooner you get the results! Start today!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 484308

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From ndersb@adformatie.nl Tue Dec 30 10:47:57 2008 Return-Path: X-Original-To: ietfarch-dhcwg-archive@core3.amsl.com Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73C83A6994 for ; Tue, 30 Dec 2008 10:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.766 X-Spam-Level: X-Spam-Status: No, score=-24.766 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYhpyncTWxmg for ; Tue, 30 Dec 2008 10:47:57 -0800 (PST) Received: from 187-26-145-104.3g.claro.net.br (187-26-145-104.3g.claro.net.br [187.26.145.104]) by core3.amsl.com (Postfix) with SMTP id 129A53A6805 for ; Tue, 30 Dec 2008 10:47:44 -0800 (PST) To: Subject: Returned mail: Quota exceeded From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080923-0, 23/09/2008), Outbound message X-Antivirus-Status: Clean Message-Id: <20081230184749.129A53A6805@core3.amsl.com> Date: Tue, 30 Dec 2008 10:47:44 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage.