RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
draft-ietf-softwire-6rd-radius-attrib-11

Thanks for addressing my Discuss and Comment in the -08 revision

Former DISCUSS point is resolved by replacing the last paragraph in Section 3 with this:

  As specified in [RFC2131], section 4.4.5, "Reacquisition and expiration",
  if the DHCP server to which the DHCP Request message was sent at time
  T1 has not responded by time T2 (typically 0.375*duration_of_lease after T1),
  the 6rd CE (the DHCP client) enters the REBINDING state and attempts to
  contact any server.  In this situation, the secondary BNG receiving the new
  DHCP message MUST initiate a new Access-Request towards the AAA
  server. The secondary BNG MAY include the IPv6-6rd-Configuration Attribute
  in its Access-Request.

=== non-blocking comments ===

-- Section 1 --
   6rd adopts Dynamic Host Configuration Protocol (DHCP) 
   [RFC2131] as auto-configuring protocol.

Do you really mean "adopts" here, or should it be "adapts"?  I'm not certain from reading the document, but they imply different things and the RFC Editor won't know whether to change it or not.

-- Section 2 --
   The terms 6rd CE and 6rd Border Relay are defined in [RFC5969]. 

It would be helpful to at least expand the terms here, so I don't have to go to 5969 for that:

NEW
   The terms 6rd Customer Edge (6rd CE) and 6rd Border Relay (BR)
   are defined in [RFC5969]. 

-- Section 3 --

The caption in Figure 2 is the same as the one in Figure 1, though it represents a different scenario.  Please change the caption to make it clear what the difference is.

-- Section 4 --
   This section defines IPv6-6rd-Configuration Attribute which is used 
   in the 6rd scenario. The attribute design follows [RFC6158]. 

In Section 3, you describe two different "scenarios".  Here, you talk about "the 6rd scenario."  Are you talking about both of them here, or just one?  Please clarify.  I think you're using "scenario" in two slightly different ways.

-- Section 4.1 --
   Since the subtypes have values, they can appear in any order. If 
   multiple 6rdBRIPv4Address (subtype 3) appear, they are recommended to 
   be placed together. 

Why are they recommended to be placed together?  What happens if they're not?  Is this just a neatness thing, or is there an actual reason for it?

-- Section 4.2 --
I'm confused by the table:
- What is the "#" heading?
- The second row appears to be quantity specifiers, except for the last two columns.  Why are they different?

Ah... Now I think I've figured out what you're doing, but I had to do it by searching all your references for "challenge", and then finding a table like the one you have here.  Please don't make people do that.

OLD
   The following table provides a guide to which attributes may be found 
   in which kinds of packets, and in what quantity. 
NEW
   The following table adds to the one in [RFC2865], Section 5.44,
   providing a guide to the quantity of IPv6-6rd-Configuration attributes
   that may be found in each kind of packet.

-- Section 7 --
   IANA should allocate the number from the standard RADIUS Attributes 
   space using the "IETF Review" policy [RFC5226]. 

The registry actually uses the old term, "IETF Consensus".  I don't think IANA will be confused, but I think it would be clearer if you specified this differently.  Also, you have to tell the RFC Editor to replace "TBD" in the document with the assigned value.  So:

NEW
   IANA should allocate the number from the standard RADIUS Attributes 
   range (values 1-191).  The RFC Editor should use the assigned value
   to replace "TBD" in Sections 4.1 and 4.2, and should remove this
   paragraph.

Thanks for addressing my DISCUSS

- You started to use the terminology from RFC 5969, but for two terms only.
It's a pity that you didn't reuse the other.
4.1. IPv6-6rd-Configuration Attribute

       6rdPrefix

         The Service Provider's 6rd IPv6 prefix represented as a 16
         octet IPv6 address. The bits after the 6rdPrefixlen number of
         bits in the prefix SHOULD be set to zero.

       ...

       6rdBRIPv4Address

         One or more IPv4 addresses of the 6rd Border Relay(s) for a
         given 6rd domain. The maximum RADIUS Attribute length of 255
         octets results in a limit of 58 IPv4 addresses. 

From RFC 5969:
   6rd prefix            An IPv6 prefix selected by the service provider
                         for use by a 6rd domain.  There is exactly one
                         6rd prefix for a given 6rd domain.  An SP may
                         deploy 6rd with a single 6rd domain or multiple
                         6rd domains.

   ...

   BR IPv4 address       The IPv4 address of the 6rd Border Relay for a
                         given 6rd domain.  This IPv4 address is used by
                         the CE to send packets to a BR in order to
                         reach IPv6 destinations outside of the 6rd
                         domain.

  In the Gen-ART Review by Pete McCann on 27-Nov-2012, this comment
  was provided:

  > IPv4MaskLen doesn't need to be any more than 8bits long.

  The authors agreed, but the document has not been updated yet.

Thanks for clearing up my discusses.

4.1: MUST the BNG use different 6rd parameters if the AAA server
has ignored the suggested configuration attribute and supplied
others in the Access-Accept? Don't you need to say that?

4.2: What would it mean to put a 6rd configuration attribute into
an accounting request? Doesn't someone need to say more about
that?

section 6: Why not consider recommending RADSEC or RADIUS over
DTLS? Maybe it'd be worth asking radext WG folks if its now
timely to start doing that?