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

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:soohong.park@samsung.com]
  Sent: Tuesday, July 13, 2004 5:54 PM
  To: Steve Gonczi; soohong.park@samsung.com
  Cc: Bernie Volz; dhcwg@ietf.org
  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