[dhcwg] Edit #3 of DHCP spec

Ralph Droms <rdroms@ch2-dhcp150-26.cisco.com> Wed, 15 May 2002 13:37 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03764 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 09:37:38 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA19928 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 09:37:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19751; Wed, 15 May 2002 09:35:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19729 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 09:35:50 -0400 (EDT)
Received: from ch2-dhcp150-26.cisco.com (ch2-dhcp150-26.cisco.com [161.44.150.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03527 for <dhcwg@ietf.org>; Wed, 15 May 2002 09:35:36 -0400 (EDT)
Received: (from rdroms@localhost) by ch2-dhcp150-26.cisco.com (8.11.6/8.11.6) id g4FDZHf01496; Wed, 15 May 2002 09:35:17 -0400
Date: Wed, 15 May 2002 09:35:17 -0400
Message-Id: <200205151335.g4FDZHf01496@ch2-dhcp150-26.cisco.com>
From: Ralph Droms <rdroms@ch2-dhcp150-26.cisco.com>
To: dhcwg@ietf.org
CC: rdroms@cisco.com
Reply-to: rdroms@cisco.com
Subject: [dhcwg] Edit #3 of DHCP spec
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

  
Narten:
  
  > 17.1.4. Receipt of Reply message
  
  >  If the client includes a Rapid Commit option in the Solicit message,
  >  it will expect a Reply message that includes a Rapid Commit option
  >  in response.  If the client receives a Reply message, it processes
  >  the message as described in section 18.1.6.  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, if the client sets the Rapid Commit, because it is in a hurry, the
  process may actually take *longer* because some servers won't respond
  unless the Rapid Commit is not present? This seems like a disincentive
  to using the mechanism, as it might not only be quicker, it might
  actually be longer, and there isn't a way for the client to know
  without just trying. Right?

Response:

Modified Rapid Commit to allow servers to respond with Advertise and
client to respond to Advertise if it does not receive a
Rapid Commit/Reply

*** dhcpv6.tty	Wed May 15 06:14:14 2002
--- dhcpv6-24.txt	Tue Apr 23 15:35:14 2002
***************
*** 1940,1951 ****
        MRD   0
  
     If the client has included a Rapid Commit option and is waiting for
!    a Reply message, the client terminates the retransmission process
!    as soon as a Reply message is received.  If the client receives an
!    Advertise message that includes a Preference option with a preference
!    value of 255, the client immediately begins a client-initiated
!    message exchange (as described in section 18) by sending a Request
!    message to the server from which the Advertise message was received.
  
  
  
--- 1939,1951 ----
        MRD   0
  
     If the client has included a Rapid Commit option and is waiting for
!    a Reply message, the client terminates the retransmission process as
!    soon as a Reply message is received.
! 
!    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
  
  
  
***************
*** 1954,1969 ****
  Internet Draft              DHCP for IPv6 (-24)              22 Apr 2002
  
  
-    If the client receives an Advertise message that does not include
-    a Preference option with a preference value of 255, the client
-    continues to wait until IRT elapses.  If IRT elapses and the client
-    has received an Advertise message, the client SHOULD continue with a
-    client-initiated message exchange by sending a Request message.
- 
-    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.  Also, the first
     RT MUST be selected to be strictly greater than IRT by choosing RAND
     to be strictly greater than 0.
--- 1954,1959 ----
***************
*** 2039,2047 ****
  17.1.4. Receipt of Reply message
  
     If the client includes a Rapid Commit option in the Solicit message,
!    it will expect a Reply message that includes a Rapid Commit option in
!    response.  If the client receives a Reply message, it processes the
!    message as described in section 18.1.6.
  
  
  17.2. Server Behavior
--- 2028,2039 ----
  17.1.4. Receipt of Reply message
  
     If the client includes a Rapid Commit option in the Solicit message,
!    it will expect a Reply message that includes a Rapid Commit option
!    in response.  If the client receives a Reply message, it processes
!    the message as described in section 18.1.6.  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.
  
  
  17.2. Server Behavior
***************
*** 2061,2081 ****
     If the client has included a Rapid Commit option in the Solicit
     message and the server has been configured to respond with committed
     address assignments and other resources, the server responds to the
!    Solicit with a Reply message as described in section 17.2.3.  If the
!    server has been configured to respond to the client but has not been
!    configured to respond with committed address assignments and other
!    resources, the server responds with an Advertise message.
  
     Otherwise, the server generates and sends an Advertise message to the
     client.
  
  
- 
- Droms (ed.), et al.            Expires 22 Oct 2002             [Page 30]
- 
- Internet Draft              DHCP for IPv6 (-24)              22 Apr 2002
- 
- 
  17.2.2. Creation and transmission of Advertise messages
  
     The server sets the "msg-type" field to ADVERTISE and copies the
--- 2053,2064 ----
     If the client has included a Rapid Commit option in the Solicit
     message and the server has been configured to respond with committed
     address assignments and other resources, the server responds to the
!    Solicit with a Reply message as described in section 17.2.3.
  
     Otherwise, the server generates and sends an Advertise message to the
     client.
  
  
  17.2.2. Creation and transmission of Advertise messages
  
     The server sets the "msg-type" field to ADVERTISE and copies the

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