<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:roberta.maglione@xxxxxxxxxxxxxxxx] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@xxxxxxxx Cc: softwires@xxxxxxxx; <dhcwg@xxxxxxxx> 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: softwires-bounces@xxxxxxxx [mailto:softwires-bounces@xxxxxxxx] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@xxxxxxxx Cc: softwires@xxxxxxxx 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: softwires-bounces@xxxxxxxx [mailto:softwires-bounces@xxxxxxxx] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@xxxxxxxx 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 ietf@xxxxxxxx mailing lists by 2012-11-29. Exceptionally, comments may be sent to iesg@xxxxxxxx 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 Softwires@xxxxxxxx https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@xxxxxxxx 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.