Subject: RE: [dhcwg] additional comments on dhcpv6-24

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 15 May 2002 15:16:00 -0500

But I would assume if you got zero Advertises back from the first transmission that it likely failed to be received by anyone (perhaps because the Relay did not forward it). That's why I think it might be best to always have the IRT time elapse. But, I fully agree that as more retransmission occur, this is less and less of an issue. And, if there is only one server, it could just as likely have been the response that was lost. But in this case, you'd set the server to use a preference of 255 and gain the benefit.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 4:03 PM
To: Bernie Volz (EUD)
Cc: [email-masked]; 'JINMEI Tatuya / ????'
Subject: Re: [dhcwg] additional comments on dhcpv6-24

> Regarding (2), good question ... I would say it should. The logic might 
> simply be send a Solicit, wait IRT, check if any Advertises received ... 
> if so, go use them otherwise send Solicit again.

I think it makes more sense to say that if IRT has elapsed since the first 
Solicit was sent, the client just takes the first Advertise it gets.   This 
is how I implemented the ISC DHCPv4 client, and it seems to work pretty 
nicely.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 16 May 2002 12:31:11 -0500

Regarding (1), please watch the mailing list as Ralph Droms is issuing update notices for changes being made.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 12:52 PM
To: Bernie Volz (EUD)
Cc: [email-masked]
Subject: Re: [dhcwg] additional comments on dhcpv6-24

>>>>> On Wed, 15 May 2002 14:36:37 -0500, 
>>>>> "Bernie Volz (EUD)" <[email-masked]> said:

> Regarding (1), based on -24 the server shouldn't be sending an
> Advertise. And, yes, I think your assumption that the client should
> discard it is correct. Having said that, I would like to see the
> Rapid Commit change to be more of just an option. A server set up to
> respond to Rapid Commit would send the Reply. Other servers could
> send an Advertise. The client would use the Reply if received;
> otherwise simply start using the Advertises as if a Solicit w/o
> Rapid Commit was done.

I'm a bit confused...so are you saying the followings?

- the client should discard the unexpected advertise *with the current
  specification*.
- but we should change the spec so that the client will accept an
  advertise.

> Regarding (2), good question ... I would say it should. The logic
> might simply be send a Solicit, wait IRT, check if any Advertises
> received ... if so, go use them otherwise send Solicit again.

Okay.  I don't have a particular opinion on this as long as the
wording is clear.

> Regarding (3), your understanding is correct. I can't see that it
> hurts for us to indicate that RAND be greater than 0.

Okay.  I would simplify the specification so that there will be no
special case, but I don't make an objection to the current spec.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]