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

From: PARK SOO HONG <[email-masked]>
Date: Tue, 13 Jul 2004 21:54:05 +0000 (GMT)

Hi Steve, thanks your comments and see my comment inline

>When the Rapid commit client decides to accept an address

>sent via a Rapid Commit ack, it should send out a DHCPREQUEST

>(perhaps with the rapid commit option),

>similar to the classic DHC protocol.

I'd keep the original sentence since to sync the operation of DHCPv6,

also make sure this option is for *RAPID COMMIT*.

Regards

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Steve Gonczi" <[email-masked]>
Date: Tue, 13 Jul 2004 19:34:44 -0400

Samsung Enterprise Portal mySingleHi Daniel,

I have to admit I am not entirely clear on what you meant,
although I suspect you disagree with my suggestion.

Let me try to make my case:

For the cost of sending out one extra message by the Rapid Commit
client (which BTW does not cause any significant delay)
you could eliminate the entire 3.2 section from your protocol.

To recap:

1)  The "no multiple servers" restriction
2)  or "must have enough addresses" restriction
3)  or "use short lease times" restriction

Why would you not want to do this?

/sG
  -----Original Message-----
  From: PARK SOO HONG [mailto:[email-masked]]
  Sent: Tuesday, July 13, 2004 5:54 PM
  To: Steve Gonczi; [email-masked]
  Cc: Bernie Volz; [email-masked]
  Subject: Re: RE: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05

  Regards

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 14 Jul 2004 08:17:18 -0400

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? 
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Steve Gonczi
Sent: Tuesday, July 13, 2004 7:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: RE: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05

Hi Daniel,

 
 
To recap:

/sG

-----Original Message-----
From: PARK SOO HONG [mailto:[email-masked]]
Sent: Tuesday, July 13, 2004 5:54 PM
To: Steve Gonczi; [email-masked]
Cc: Bernie Volz; [email-masked] 
Subject: Re: RE: [dhcwg] dhc WG last call on

 

 

 

Regards

---

From: Mark Stapp <[email-masked]>
Date: Wed, 14 Jul 2004 09:02:00 -0400

I agree with Bernie. It's true that sending the extra 'REQUEST' is 
inexpensive, but it's just another unreliable UDP packet. I don't think 
that the suggested extra step provides enough benefit to be worth including.

-- Mark

---

From: "Steve Gonczi" <[email-masked]>
Date: Wed, 14 Jul 2004 15:14:52 -0400

MessageWould 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:[email-masked]]
  Sent: Wednesday, July 14, 2004 8:17 AM
  To: 'Steve Gonczi'; [email-masked]
  Cc: [email-masked]
  Subject: RE: RE: [dhcwg] dhc WG last call on

  - Berni

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 15 Jul 2004 00:24:44 -0400

>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:[email-masked]] 
Sent: Wednesday, July 14, 2004 3:15 PM
To: Bernie Volz
Cc: [email-masked]
Subject: RE: RE: [dhcwg] dhc WG last call on

Would not get retransmitted,  and I did not propose 
an ACK/ NAK. 

 

 
regards,
 
/sG

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Wednesday, July 14, 2004 8:17 AM
To: 'Steve Gonczi'; [email-masked]
Cc: [email-masked]
Subject: RE: RE: [dhcwg] dhc WG last call on

- Berni

---

From: "Steve Gonczi" <[email-masked]>
Date: Thu, 15 Jul 2004 14:31:50 -0400

MessageHi Bernie,

My thinking was exactly as you outline it below. (the DHCPREQUEST
would have the rapid commit option...)

In any case, the point is moot, as I have come around to seeing
the beauty of using initial short leases.

I presume that the intent is to get the client IP-enabled as fast as
possible,
whilst the cost of the almost immediate renewal is not relevant.

I did post a note of supporting the advancement of this draft as-is.

/sG

  -----Original Message-----
  From: Bernie Volz [mailto:[email-masked]]
  Sent: Thursday, July 15, 2004 12:25 AM
  To: 'Steve Gonczi'
  Cc: [email-masked]
  Subject: RE: RE: [dhcwg] dhc WG last call on

  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