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

["Bernie Volz" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Steve Gonczi
Sent: Tuesday, July 13, 2004 7:35 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: RE: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05


Hi 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:[e-mail]]
Sent: Tuesday, July 13, 2004 5:54 PM
To: Steve Gonczi; [e-mail]
Cc: Bernie Volz; [e-mail] 
Subject: Re: RE: [dhcwg] dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-05



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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg