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

From: The IESG <[email-masked]>
Date: Thu, 15 Nov 2012 13:39:18 -0800

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-masked] mailing lists by 2012-11-29. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 16 Nov 2012 20:43:47 +0800

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-masked] [mailto:[email-masked]] On
Behalf Of The IESG
Sent: Friday, November 16, 2012 5:39 AM
To: IETF-Announce
Cc: [email-masked]
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-masked] mailing lists by 2012-11-29. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot
/

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 16 Nov 2012 14:13:00 +0100

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.

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-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Friday, November 16, 2012 1:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard

Best Regards,
Leaf

-----Original Message-----

Abstract

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.

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 16 Nov 2012 21:57:43 +0800

<Roberta> According to section 4.4.5 of RFC 2131:
</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-masked]] 
Sent: Friday, November 16, 2012 9:13 PM
To: 'Leaf Yeh'; [email-masked]
Cc: [email-masked]; <[email-masked]> WG
Subject: RE: [Softwires] Last Call:

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.

Why T2?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Leaf Yeh
Sent: Friday, November 16, 2012 1:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Softwires] Last Call:
<draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to
Proposed Standard

Best Regards,
Leaf

-----Original Message-----

Abstract

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.

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 16 Nov 2012 15:09:11 +0100

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:[email-masked]]
Sent: Friday, November 16, 2012 2:58 PM
To: Maglione Roberta; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard

Best Regards,
Leaf

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: Friday, November 16, 2012 9:13 PM
To: 'Leaf Yeh'; [email-masked]
Cc: [email-masked]; <[email-masked]> WG
Subject: RE: [Softwires] Last Call:

Hi Leaf,

Why T2?

-----Original Message-----

Best Regards,
Leaf

-----Original Message-----

Abstract

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 19 Nov 2012 02:10:23 +0000

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

>Sent: Friday, November 16, 2012 10:09 PM
>To: 'Leaf Yeh'; Sheng Jiang
>Cc: [email-masked]; [email-masked]; [email-masked]
>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.
>
>Subject: RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt>
>(RADIUS Attribute for 6rd) to Proposed Standard
>
>at
>persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
>conoscenza di queste informazioni sono rigorosamente vietate. Qualora