<Roberta> According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. </Roberta>
Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING state and attempts to contact any possible server. '? Best Regards, Leaf -----Original Message----- From: Maglione Roberta [mailto:[email protected]] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; [email protected] Cc: [email protected]; <[email protected]> WG Subject: RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: [email protected] Cc: [email protected] Subject: Re: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: [email protected] Subject: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' <draft-ietf-softwire-6rd-radius-attrib-07.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email protected] mailing lists by 2012-11-29. Exceptionally, comments may be sent to [email protected] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
