RE: [dhcwg] additional comments on dhcpv6-24

Jinmei:

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.

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.

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

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp]
Sent: Wednesday, May 15, 2002 2:17 PM
To: dhcwg@ietf.org
Subject: [dhcwg] additional comments on dhcpv6-24

I have some additional comments (and questions) on dhcpv6-24,
particularly about server solicitation.

(1) If the client sent a solicit message with a rapid commit option
    but the server responds to the solicitation with an advertise
    message, what should the client do?  Should it ignore the
    advertise, should it accept the advertise and send a request, or
    others?  Section 17.1.4 says

     ...If the client does not
     receive a Reply message, the client restarts the server solicitation
     process by sending a Solicit message that does not include a Rapid
     Commit option.

   So, the client should probably ignore the advertise (and keep
   waiting for a reply.)  But I'm not 100% sure about this.

(2) Section 17.1.2 says:

   If the client is waiting for an Advertise message, the mechanism in
   section 14 is modified as follows for use in the transmission of
   Solicit messages.  The message exchange is not terminated by the
   receipt of an Advertise before IRT has elapsed.  Rather, the client
   collects Advertise messages until IRT has elapsed.

Should this rule apply if the client is retransmitting solicit
messages?  For example, suppose that there is no advertise in response
to the first solicit, and so the client retransmit the solicit.  If
the client then receives a first advertise, should it still wait until
IRT elapses?

(3) The paragraph above then says:
   Also, the first
   RT MUST be selected to be strictly greater than IRT by choosing RAND
   to be strictly greater than 0.

However, according to Section 13, the first RT should be

      RT = 2*IRT + RAND*IRT

where  RAND is a random number chosen with a uniform distribution
between -0.1 and +0.1.  Thus,

      RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT
      (the rightmost '=' is satisfied only when IRT is 0)

So the RT should always be greater than IRT regardless of the value of
RAND, and "by choosing RAND to be strictly greater than 0" seems to be
redundant.  Is my understanding correct?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

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