RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05

"Bernie Volz" <volz@cisco.com> Thu, 15 July 2004 04:38 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07676; Thu, 15 Jul 2004 00:38:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkxuJ-000809-Pw; Thu, 15 Jul 2004 00:31:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkxpe-0006ts-9z for dhcwg@megatron.ietf.org; Thu, 15 Jul 2004 00:26:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07190 for <dhcwg@ietf.org>; Thu, 15 Jul 2004 00:26:51 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkxpc-0006rL-AK for dhcwg@ietf.org; Thu, 15 Jul 2004 00:26:52 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkxoc-0006YC-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 00:25:51 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Bkxo6-0006Dy-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 00:25:18 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2004 21:26:15 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6F4OkRo002913; Wed, 14 Jul 2004 21:24:47 -0700 (PDT)
Received: from volzw2k (che-vpn-cluster-2-208.cisco.com [10.86.242.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKD30449; Thu, 15 Jul 2004 00:24:45 -0400 (EDT)
From: Bernie Volz <volz@cisco.com>
To: 'Steve Gonczi' <steve@relicore.com>
Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05
Date: Thu, 15 Jul 2004 00:24:44 -0400
Organization: Cisco
Message-ID: <000501c46a23$a85fd970$18fc7044@amer.cisco.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
Importance: Normal
In-Reply-To: <BFELJLKGHEJOPOPGJBKKMEHLCJAA.steve@relicore.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2064973252=="
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

>Would not get retransmitted,  and I did not propose 
>an ACK/ NAK. 
 
Well, you didn't propose the ACK/NAK but the server will send that back in
response to DHCPREQUEST. Or, are you also suggesting that more is changed to
include the "Rapid Commit" in the DHCPREQUEST such that the server knows not
to send the ACK (or NAK)?
 
Again, if you want to do this use short lease times for the Rapid Commit and
give the client a full length lease when it renews.
 
- Bernie

-----Original Message-----
From: Steve Gonczi [mailto:steve@relicore.com] 
Sent: Wednesday, July 14, 2004 3:15 PM
To: Bernie Volz
Cc: dhcwg@ietf.org
Subject: RE: RE: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05


Would not get retransmitted,  and I did not propose 
an ACK/ NAK. 
 
Merely a best effort DHCPREQUEST,  to give any server
that committed and address (but was not selected by the client)
a chance to clean up.
 
This DHCPREQUEST is not intended for the server that offered
the accepted ( and committed) address. 
 
That server does not need to do anything further.
 
BTW this is exactly how plain DHCP works today.
Any server that did offer an address, and sees the DHCPREQUEST
for a different address, just releases  the address and there is no further
action required. Neither does DHCP provide any assurance that
any (not selected) server does see the DHCPREQUEST.
 
 
 
regards,
 
/sG
 

-----Original Message-----
From: Bernie Volz [mailto:volz@cisco.com]
Sent: Wednesday, July 14, 2004 8:17 AM
To: 'Steve Gonczi'; soohong.park@samsung.com
Cc: dhcwg@ietf.org
Subject: RE: RE: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05


This likely isn't as a cut and dry as you assume. Does the DHCPREQUEST get
retransmitted until it is ACKed? What happens if it isn't ACKed? What
happens if it is NAK? 
 
- Berni

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