RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard

[Sheng Jiang <[e-mail]>]

Hi, Roberta and Leaf,

Carefully checked RFC2131, the original text was right, but not clearly define the time that client enters REBINDING state. So Leaf's comments also right. New text will be the below. It would be added after AD's instruction for next update, maybe with other comments from IESG. 

If the DHCP server to which the DHCP Request message was sent at time 
   T1 has not responded "till T2", the DHCP client enters the REBINDING state and 
   attempts to contact any server.

Many thanks and best regards,

Sheng

>-----Original Message-----
>From: Maglione Roberta [mailto:[e-mail]]
>Sent: Friday, November 16, 2012 10:09 PM
>To: 'Leaf Yeh'; Sheng Jiang
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt>
>(RADIUS Attribute for 6rd) to Proposed Standard
>
>Leaf,
>In my opinion current text is fine and inline with RFC2131, while the text you
>are proposing is not completely accurate because it does not clarify "which
>DHCP Server" has not replied.
>
>'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. '
>
>Sheng,
> As original author of this text, what do you think?
>
>Thanks,
>Roberta
>
>-----Original Message-----
>From: Leaf Yeh [mailto:[e-mail]]
>Sent: Friday, November 16, 2012 2:58 PM
>To: Maglione Roberta; [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt>
>(RADIUS Attribute for 6rd) to Proposed Standard
>
><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:[e-mail]]
>Sent: Friday, November 16, 2012 9:13 PM
>To: 'Leaf Yeh'; [e-mail]
>Cc: [e-mail]; <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
>Behalf Of Leaf Yeh
>Sent: Friday, November 16, 2012 1:44 PM
>To: [e-mail]
>Cc: [e-mail]
>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-para
>meters
>.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: [e-mail] [mailto:[e-mail]] On
>Behalf Of The IESG
>Sent: Friday, November 16, 2012 5:39 AM
>To: IETF-Announce
>Cc: [e-mail]
>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
>[e-mail] mailing lists by 2012-11-29. Exceptionally, comments may be
>sent to [e-mail] 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/softwires
>
>_______________________________________________
>Softwires mailing list
>[e-mail]
>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.
>
>
>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.