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

[Ballot comment]
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.

[Ballot discuss]
1. addressed in -08

2. addressed in -10

3.  A RADIUS message used for call-check does not contain any information that would authenticate the request and is therefore susceptible to forgery.  Therefore, RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet.

The "Call Check" Service-Type was designed for situations where authorization can be determined via the Called-Station-Id or Calling-Station-Id attributes, which originally contained telephone numbers.  In RFC 3580, Called/Calling-Station-Id could also contain a MAC address, but the principle was similar -- an unique (non-authenticated) identifier which could be used to determine whether a call was authorized.

However, this draft does not say anything about use of the Calling-Station-Id or Called-Station-Id attributes, or the value of the User-Name attribute.  Given that, the use of Service-Type = "Call Check" would not seem to apply.

For -08, author agreed to include:

"According to [RFC2865], it is recommended that the Access-Requests use the value of Calling-Station-Id as the value of the User-Name."

but it didn't seem to make it in to -08.

Trying to get aaa-doctors to provide some feedback on this issue.

4. addressed in -08

5. addressed in -08

6. addressed in -08

[Ballot discuss]
The AAA doctors reviewed version 10

1. While Section 3 now does describe how authentication/authorization functions in a way that is compliant with RFC 2865 and 5080, there is no normative language and the requirements (e.g. for User-Name and User-Password attributes, Message-Authenticator attribute) are not included in Section 4.2. 

2. Section 6 (Security Considerations) has a dangling sentence:

...

  The MAC address spoofing is possible

...

  OK... then what?

[Ballot comment]
- Also, it would be helpful to be explicit about the value of the Service-Type attribute in Access-Requests (I am assuming that this is no longer "Call-Check", since the User-Password attribute is included in the Access-Request).

- You started to use the terminology from RFC 5969, but for two terms only.
It's a pity that you didn't reuse so 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.

[Ballot discuss]
1. addressed in -08

2. There are two protocols (DHCP and RADIUS) being used in f1/2, but the security considerations only discusses how to secure the RADIUS part.  A pointer to the 6rd RFC/draft that discusses how to secure the CE<->BNG bit (i.e., DHCP), I believe, is warranted.  A follow on, is what security concerns are there for a rogue CE gather information about other CE's on the ISPs networked?

3.  A RADIUS message used for call-check does not contain any information that would authenticate the request and is therefore susceptible to forgery.  Therefore, RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet.

The "Call Check" Service-Type was designed for situations where authorization can be determined via the Called-Station-Id or Calling-Station-Id attributes, which originally contained telephone numbers.  In RFC 3580, Called/Calling-Station-Id could also contain a MAC address, but the principle was similar -- an unique (non-authenticated) identifier which could be used to determine whether a call was authorized.

However, this draft does not say anything about use of the Calling-Station-Id or Called-Station-Id attributes, or the value of the User-Name attribute.  Given that, the use of Service-Type = "Call Check" would not seem to apply.

For -08, author agreed to include:

"According to [RFC2865], it is recommended that the Access-Requests use the value of Calling-Station-Id as the value of the User-Name."

but it didn't seem to make it in to -08.

4.  Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user? If this is the case then the BNG may have received a state attribute in the access-accept message. Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction. If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service. Also, if it is the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange.

When DHCP information is retrieved along with user authentication why is either Authorize-Only or Call Check needed?

5. addressed in -08

6. addressed in -08

[Ballot comment]
1) s1: r/transit/transition

2) s2: Just some tweaking:

OLD:

  In 6rd scenarios, both CE and BNG are within a provider network,
  which can be considered as a close and less security threat
  environment.

NEW:

  In 6rd scenarios, both CE and BNG are within a provider network,
  which can be considered as a closed network and a lower security threat
  environment.

[Ballot comment]
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.

[Ballot comment]

  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.

[Ballot discuss]
The issue raised by Bernard Adoba (aaa-doctors) has not been addressed in version 7.
See http://www.ietf.org/mail-archive/web/aaa-doctors/current/msg00738.html

RFC 5080 Section 2.1.1 lays out the requirements for use of a State attribute:

  The only permissible values for a State attribute are values provided
  in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
  Request packet.  A RADIUS client MUST use only those values for the
  State attribute that it has previously received from a server.  An
  Access-Request sent as a result of a new or restarted authentication
  run MUST NOT include the State attribute, even if a State attribute
  has previously been received in an Access-Challenge for the same user
  and port.


This requirement exists to ensure that a State attribute ties back to an authenticated RADIUS session.

Within the document, the flow diagram describes "cooperation between DHCP and RADIUS":

    6rd CE                      BNG                      AAA Server
        |                          |                            |
        |-------DHCPDISCOVER------>|                            |
        |                          |--Access-Request(6rd Attr)-->|
        |                          |                            |
        |                          |<--Access-Accept(6rd Attr)---|
        |<-------DHCPOFFER---------|                            |
        |                          |                            |
        |--------DHCPREQUEST------>|                            |
        |      (6rd Option)        |                            |
        |<--------DHCPACK----------|                            |
        |      (6rd option)        |                            |
        |                          |                            |
                  DHCP                        RADIUS
                Figure 1: the cooperation between DHCP and RADIUS


This diagram neither indicates that the RADIUS Access-Request/Accept sequence is authenticated, nor does it show any previous previous authenticated RADIUS interaction.  It therefore appears to violate the RFC 5080 requirement.

[Ballot comment]
- While reading, I flagged the same DISCUSS as Barry regarding T1 in the following sentence:
  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. In this scenario the BNG receiving
  the DHCP message MUST initiate a new Access-Request towards the AAA
  server.


- You started to use the terminology from RFC 5969, but for two terms only.
It's a pity that you didn't reuse so 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.


-
  The IPv6-6rd-Configuration Attribute MAY be used in Access-Request
  packets as a hint to the RADIUS server
You should also mention in this section the normal case (the Access-Accept) before treating the exceptions.

IANA has reviewed draft-ietf-softwire-6rd-radius-attrib-07 and has
the following comments:

Upon approval of this document, IANA understands that there is a single
action which IANA must complete.

In the Radius Attribute Types subregistry of the Radius Types registry located at:

http://www.iana.org/assignments/radius-types

a new Radius Attribute Type will be allocated from the IETF Consensus part of
the subregistry as follows:

Value: [ TBD ]
Description: IPv6-6rd-Configuration
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon
approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

[Ballot discuss]
Some of these are from the secdir review (and subsequent exchanges between some AAA/RADIUS folks):

1. 6rd is all done on the SP's network so I'm just checking that it's implied that the CE and BNG have a pre-established trust relationship.  I went looking for this kind of statement in RFC 5969 and couldn't find the description for a BNG.  It would be good to state this (or whatever it is) explicitly in the security considerations.

2. There are two protocols (DHCP and RADIUS) being used in f1/2, but the security considerations only discusses how to secure the RADIUS part.  A pointer to the 6rd RFC/draft that discusses how to secure the CE<->BNG bit (i.e., DHCP), I believe, is warranted.  A follow on, is what security concerns are there for a rogue CE gather information about other CE's on the ISPs networked?

3.  A RADIUS message used for call-check does not contain any information that would authenticate the request and is therefore susceptible to forgery.  Therefore, RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet.

The "Call Check" Service-Type was designed for situations where authorization can be determined via the Called-Station-Id or Calling-Station-Id attributes, which originally contained telephone numbers.  In RFC 3580, Called/Calling-Station-Id could also contain a MAC address, but the principle was similar -- an unique (non-authenticated) identifier which could be used to determine whether a call was authorized.

However, this draft does not say anything about use of the Calling-Station-Id or Called-Station-Id attributes, or the value of the User-Name attribute.  Given that, the use of Service-Type = "Call Check" would not seem to apply.

4.  Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user? If this is the case then the BNG may have received a state attribute in the access-accept message. Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction. If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service. Also, if it is the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange.

When DHCP information is retrieved along with user authentication why is either Authorize-Only or Call Check needed?

5.  It was not clear in the specification what is sent in the access-request message.  Is the BNG looking to get a IPv6-6rd-configuration attribute in the access accept? It seems that you would need to send this attribute in the request if you expected it in the response or else the AAA server would not be able to un-ambiguously be able to service the request; there are other uses for the call-check service. I think you should specify that the 6rd attribute must be in the request if you want to see it in the response.

6. s4.1: Need to specify how the reserved bits are handled.  Normally it's:

The bits MUST be set to zero by the
sender and MUST be ignored by the receiver.

[Ballot comment]
1) abstract: This sounds a little like marketing to me:

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.

Maybe:

IPv6 Rapid Deployment (6rd)
provides both IPv4 and IPv6 connectivity services simultaneously
during the IPv4/IPv6 co-existing period.

2) s1: r/Recently providers start to/Recently providers have started to
3) s1: r/transit/transition
4) s1: r/is one of the most popular methods to provide/provides
5) s1: r/may be/is
6) s4.1: r/recommended/RECOMMENDED ?

[Ballot discuss]
-- 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. In this scenario the BNG receiving
  the DHCP message MUST initiate a new Access-Request towards the AAA
  server.

"Time T1" isn't shown in any figure, defined anywhere, or used anywhere else.  Further, it's not at all clear to me how this is meant to work.  Is there some DHCP Request message that we're not seeing in Figure 2?  If not, then the BNG is the DHCP server, and the 6rd CE is the DHCP client, as I see in the diagram, yes?  You say if it "has not responded"... has not responded by when?  Then you say that if it has not responded, the client "attempts to contact any server."  But then you want the BNG to do something relative to this request... what happens when the client succeeds in contacting a *different* server, while this BNG thinks it's still serving this request?

[Ballot comment]
-- 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.

[Ballot discuss]
This should be an easy thing to resolve:
- a quick email to me to tell me there is nothing to worry about
- an RFC Editor note to fix the text

RFC 3588 has been obsoleted by 6733.
I would like to know that the change is just a simple fix of the
citation. I am concerned about what may have changed when 3588 was
obsoleted.

[Ballot comment]

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?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (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'
  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@ietf.org mailing lists by 2012-11-29. Exceptionally, comments may be
sent to iesg@ietf.org 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.

>(1) What type of RFC is being requested (BCP, Proposed Standard,
>Internet Standard, Informational, Experimental, or Historic)? Why
>is this the proper type of RFC? Is this type of RFC indicated in the
>title page header?

Intended status: Standards Track.
This document defines a new RADIUS attribute to carry 6rd configuration
information from AAA server to BNG.

>
>(2) The IESG approval announcement includes a Document Announcement
>Write-Up. Please provide such a Document Announcement Write-Up. Recent
>examples can be found in the "Action" announcements for approved
>documents. The approval announcement contains the following sections:
>
>Technical Summary

IPv6 Rapid Deployment (6rd) provides IPv6 connectivity over legacy
IPv4-only infrastructure. 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 AAA servers, while users may be configured by Broadband Network
Gateway (BNG) through DHCP. This document defines a RADIUS attribute
that carries 6rd configuration information from AAA server to BNG.


>Working Group Summary
>
> Was there anything in WG process that is worth noting? For
> example, was there controversy about particular points or
> were there decisions where the consensus was particularly
> rough?

This document was discussed in depth and well-reviewed. The
document was also presented and reviewed in wg radext.
WG consensus is strong to publish this document.
The authors also revised the document based on the review
comments given by IESG on a similar document, RADIUS Extensions
for Dual-Stack Lite, RFC 6519.


>
>Document Quality
>
> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to
> implement the specification? Are there any reviewers that
> merit special mention as having done a thorough review,
> e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If
> there was a MIB Doctor, Media Type or other expert review,
> what was its course (briefly)? In the case of a Media Type
> review, on what date was the request posted?

As far as we know, there is no existing implementation yet.
A couple of vendors may have the plan to implement.
This may not be counted as a significant number, yet.

>
>Personnel
>
> Who is the Document Shepherd? Who is the Responsible Area
> Director?

Softwire co-chair, Yong Cui, is the Document Shepherd.
Ralph Droms is the Responsible AD.


>
>(3) Briefly describe the review of this document that was performed by
>the Document Shepherd. If this version of the document is not ready
>for publication, please explain why the document is being forwarded to
>the IESG.

The document is well writen and ready for publication.

>
>(4) Does the document Shepherd have any concerns about the depth or
>breadth of the reviews that have been performed?

No.
>
>
>(5) Do portions of the document need review from a particular or from
>broader perspective, e.g., security, operational complexity, AAA, DNS,
>DHCP, XML, or internationalization? If so, describe the review that
>took place.

No.
>
>(6) Describe any specific concerns or issues that the Document Shepherd
>has with this document that the Responsible Area Director and/or the
>IESG should be aware of? For example, perhaps he or she is uncomfortable
>with certain parts of the document, or has concerns whether there really
>is a need for it. In any event, if the WG has discussed those issues and
>has indicated that it still wishes to advance the document, detail those
>concerns here.

N/A.
>
>(7) Has each author confirmed that any and all appropriate IPR
>disclosures required for full conformance with the provisions of BCP 78
>and BCP 79 have already been filed. If not, explain why.

Yes.
>
>(8) Has an IPR disclosure been filed that references this document?
>If so, summarize any WG discussion and conclusion regarding the IPR
>disclosures.

No IPR issue.
>
>(9) How solid is the WG consensus behind this document? Does it
>represent the strong concurrence of a few individuals, with others
>being silent, or does the WG as a whole understand and agree with it?

This document was revised based on the discussion in wg meetings
and mailinglist.
The WG consensus is strong and most of the active participants
strongly agree on the advancement of this document.

>
>(10) Has anyone threatened an appeal or otherwise indicated extreme
>discontent? If so, please summarise the areas of conflict in separate
>email messages to the Responsible Area Director. (It should be in a
>separate email because this questionnaire is publicly available.)

No.

>
>(11) Identify any ID nits the Document Shepherd has found in this
>document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
>Checklist). Boilerplate checks are not enough; this check needs to be
>thorough.

No nits issues.
>
>
>(12) Describe how the document meets any required formal review
>criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.
>
>(13) Have all references within this document been identified as
>either normative or informative?

Yes.

>
>(14) Are there normative references to documents that are not ready for
>advancement or are otherwise in an unclear state? If such normative
>references exist, what is the plan for their completion?

No.
>
>(15) Are there downward normative references references (see RFC 3967)?
>If so, list these downward references to support the Area Director in
>the Last Call procedure.
>
No.

>
>(16) Will publication of this document change the status of any
>existing RFCs? Are those RFCs listed on the title page header, listed
>in the abstract, and discussed in the introduction? If the RFCs are not
>listed in the Abstract and Introduction, explain why, and point to the
>part of the document where the relationship of this document to the
>other RFCs is discussed. If this information is not in the document,
>explain why the WG considers it unnecessary.

No.
>
>(17) Describe the Document Shepherd's review of the IANA considerations
>section, especially with regard to its consistency with the body of the
>document. Confirm that all protocol extensions that the document makes
>are associated with the appropriate reservations in IANA registries.
>Confirm that any referenced IANA registries have been clearly
>identified. Confirm that newly created IANA registries include a
>detailed specification of the initial contents for the registry, that
>allocations procedures for future registrations are defined, and a
>reasonable name for the new registry has been suggested (see RFC 5226).

This document requires the assignment of one new RADIUS Attribute Types
in the "Radius Types" registry and it is clearly identified.

>
>(18) List any new IANA registries that require Expert Review for future
>allocations. Provide any public guidance that the IESG would find
>useful in selecting the IANA Experts for these new registries.

No requirement.
>
>(19) Describe reviews and automated checks performed by the Document
>Shepherd to validate sections of the document written in a formal
>language, such as XML code, BNF rules, MIB definitions, etc.

N/A.