RADIUS Extensions for Dual-Stack Lite
draft-ietf-softwire-dslite-radius-ext-07

[Ballot comment]
4) in 4.1, "The Change-of-Authorization (CoA) message [RFC5176] can be used to modify the current established DS-Lite tunnel." Should this be MUST be used, to ensure interoperability? or maybe RECOMMENDED, with mention of possible alternative approaches?

[Ballot discuss]
updated for revision -06

7) in 6, I disagree this attribute has no security impact beyond the basic RADIUS security consdierations. Could a MTM send multiple of access-requests with different names resulting in a denial of service attack? Especially since this attribute forces all existing tunnels to be terminated and re-established, this could generate a lot of traffic, a lot of processing overhead, and a lot of interruption of user's work..

[Ballot discuss]
Updated DISCUSS - taking out one issue that was resolved in draft-05.

The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring.

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
  Access-Request packets that contain a Service-Type attribute with the
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.  This last requirement often means that an Access-
  Accept needs to contain a State attribute, which can then be used in
  a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
  (Note 1) Where NAS or session identification attributes are included
  in Disconnect-Request or CoA-Request packets, they are used for
  identification purposes only.  These attributes MUST NOT be used for
  purposes other than identification (e.g., within CoA-Request packets
  to request authorization changes).

[Ballot comment]
1. The use of keywords in section 3 seems inconsistent. Why are the 'may' and 'shall' in the second paragraph of the section non-capitalized, while in the rest of the section the keywords are capitalized.

> This list may also contain the AFTR Tunnel Name.  When
  the NAS receives a DHCPv6 client request containing the DS-Lite
  tunnel Option, the NAS shall use the name returned in the RADIUS DS-
  Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME
  option in the DHCPv6 reply message.

2. I support item #2 in David's DISCUSS about the need to document the operational considerations of the NAS configuration and device configuration changes.

3. Two of the AAA-Doctors made in early reviews the comment that it was not clear why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here. One of them even proposed an alternative based on RFC2868 but authors argued that their approach was better… that may be true, but it would have been good to document the decision and explain why the alternative was rejected.

[Ballot discuss]
Updated DISCUSS - taking out one issue that was resolved in draft-05.

The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring.

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
  Access-Request packets that contain a Service-Type attribute with the
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.  This last requirement often means that an Access-
  Accept needs to contain a State attribute, which can then be used in
  a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
  (Note 1) Where NAS or session identification attributes are included
  in Disconnect-Request or CoA-Request packets, they are used for
  identification purposes only.  These attributes MUST NOT be used for
  purposes other than identification (e.g., within CoA-Request packets
  to request authorization changes).


3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.  Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:
  This attribute MAY be used in Access-Accept packets as a hint to the
  RADIUS server; for example if the NAS is pre-configured with a
  default tunnel name, this name MAY be inserted in the attribute.  The
  RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
  different AFTR tunnel name.

[Ballot discuss]
Slightly edited version. Please use this one.

The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring.

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
  Access-Request packets that contain a Service-Type attribute with the
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.  This last requirement often means that an Access-
  Accept needs to contain a State attribute, which can then be used in
  a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
  (Note 1) Where NAS or session identification attributes are included
  in Disconnect-Request or CoA-Request packets, they are used for
  identification purposes only.  These attributes MUST NOT be used for
  purposes other than identification (e.g., within CoA-Request packets
  to request authorization changes).


3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.  Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:
  This attribute MAY be used in Access-Accept packets as a hint to the
  RADIUS server; for example if the NAS is pre-configured with a
  default tunnel name, this name MAY be inserted in the attribute.  The
  RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
  different AFTR tunnel name.

[Ballot discuss]
Slightlhy edited version. Please use this one.

The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring.

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
  Access-Request packets that contain a Service-Type attribute with the
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.  This last requirement often means that an Access-
  Accept needs to contain a State attribute, which can then be used in
  a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
  (Note 1) Where NAS or session identification attributes are included
  in Disconnect-Request or CoA-Request packets, they are used for
  identification purposes only.  These attributes MUST NOT be used for
  purposes other than identification (e.g., within CoA-Request packets
  to request authorization changes).


3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.  Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:
  This attribute MAY be used in Access-Accept packets as a hint to the
  RADIUS server; for example if the NAS is pre-configured with a
  default tunnel name, this name MAY be inserted in the attribute.  The
  RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
  different AFTR tunnel name.

[Ballot discuss]
The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring.

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
  Access-Request packets that contain a Service-Type attribute with the
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.  This last requirement often means that an Access-
  Accept needs to contain a State attribute, which can then be used in
  a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
  (Note 1) Where NAS or session identification attributes are included
  in Disconnect-Request or CoA-Request packets, they are used for
  identification purposes only.  These attributes MUST NOT be used for
  purposes other than identification (e.g., within CoA-Request packets
  to request authorization changes).


3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.  Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:
  This attribute MAY be used in Access-Accept packets as a hint to the
  RADIUS server; for example if the NAS is pre-configured with a
  default tunnel name, this name MAY be inserted in the attribute.  The
  RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
  different AFTR tunnel name.

[Ballot comment]
1. The use of kewords in section 3 seems inconsistent. Why are the 'may' and 'shall' in the second paragraph of the section non-capitalized, while in the rest of the section the keywords are capitalized.

> This list may also contain the AFTR Tunnel Name.  When
  the NAS receives a DHCPv6 client request containing the DS-Lite
  tunnel Option, the NAS shall use the name returned in the RADIUS DS-
  Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME
  option in the DHCPv6 reply message.

2. I support item #2 in David's DISCUSS about the need to document the operational considerations of the NAS configuration and device configuration changes.

3. Two of the AAA-Doctors made in early reviews the comment that it was not clear why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here. One of them even proposed an alternative based on RFC2868 but authors argued that their approach was better… that may be true, but it would have been good to document the decision and explain why the alternative was rejected.

[Ballot discuss]
The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list.

1. As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:
  Access-Request packets that contain a Service-Type attribute with the
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.  This last requirement often means that an Access-
  Accept needs to contain a State attribute, which can then be used in
  a later Access-Request that performs authorization checks.

2. The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

3. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.
  (Note 1) Where NAS or session identification attributes are included
  in Disconnect-Request or CoA-Request packets, they are used for
  identification purposes only.  These attributes MUST NOT be used for
  purposes other than identification (e.g., within CoA-Request packets
  to request authorization changes).


Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.  Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:
  This attribute MAY be used in Access-Accept packets as a hint to the
  RADIUS server; for example if the NAS is pre-configured with a
  default tunnel name, this name MAY be inserted in the attribute.  The
  RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
  different AFTR tunnel name.

[Ballot discuss]
1) in 4.1,"This attribute MAY be used in Access-Accept packets as a hint to the RADIUS server; for example if the NAS is pre-configured with a default tunnel name, this name MAY be inserted in the attribute. "
Is the hint to the server inserted in the Access-Accept packet (which comes FROM the server), or the Access-Request (which is sent to the server) packet?
2) in 4.1, "If the NAS is pre-provisioned with a default AFTR tunnel name and the AFTR tunnel name received in Access-Accept is different from the configured default, then the AFTR tunnel name received from the AAA server MUST overwrite the pre-configured default on the NAS. " Why does this overwrite the preconfigured default? An administrator may have pre-configured the default; so the RADIUS server is asserting itself OVER the administrator? Apparently AAA is asserting itself as the master of configuration OVER both DHCP and any human adminstrators. What happens when the next person logs into the same NAS? Do they get redirected into the same tunnel, even though the default would have been approrpiate for them?
Operators have been pretty clear in the past, notably in the COPS-PR discussions - automated provisioning should NOT overwrite manual-configuration because the operators may know something that a AAA server or policy server does not. For example, an admin might modify the default tunnel becaue they are troubleshooting a reported problem with a given default tunnel; if somebody requests a session while the admin is troubleshooting, the AAA server could change the default out from under the operator. That is a bad thing; you could use a compromise, where there is a setting on the device (or a hueristic) that says the configured default should NOT be changed by action of the AAA server. We had a similar debate in ISMS, and determined that it could create security vulnerabilities and create operations problems to overwrite an adminstratively-set VACM configuration. See RFC6065 7.2.4
Maybe there should be a mechanism for an operator to determine that AAA modified the device configuration, and possibly a mechanism to identify WHICH AAA server made the change.
At a minimum, the security and operational considerations should be documented on this design decision.
3) This is a DISCUSS-DISCUSS related to point 2 - I think AAA proposals are drifting from **authorizing sessions** - REQUIRING specific settings be used for a specific user session - into **provisioning sessions** - MODIFYING the settings for functionality used in a specific user session - and into configuration - modifying the DEVICE CONFIGURATION (such as defaults). This could affect all future AAA sessions, but also other functionalities.  The device may have been purposefully configured to have settings different than the session-specific setting required for a particular user. The configuration may have been set by other means, such as DHCP, Netconf, SNMP, CLI, and so on. Functions other than the service/session being authorized/provisioned by AAA may have dependencies on the existing defaults or other non-session-specific configuration.
Based on my experience with SNMP, Netconf, COS-PR, and the "Operators' World Tour", I think AAA-overwriting of a **non-session-specific** device configuration is a mistake.
(I'm not thrilled with AAA expanding from authorizing to provisioning, but as long as provisioing is session-specific, I can live with that. But modifying device configuration, especially without addressing the issues related to coexistence with SNMP/Netconf/DHCP and other configuration protocols and their data models such as MIBs that might specify very specific behaviors, is a serious problem.)
4) in 4.1, "The Change-of-Authorization (CoA) message [RFC5176] can be used to modify the current established DS-Lite tunnel." Should this be MUST be used, to ensure interoperability? or maybe RECOMMENDED, with mention of possible alternative approaches?
5) in 4.1, [...] "Upon receiving the new AFTR tunnel name the B4 MUST terminate the current DS-Lite tunnel and the B4 MUST establish a new DS-LITE tunnel with specified AFTR."
This normative text (MUST terminate) is within a paragraph that starts with CoA "can be used" (which is obviously optional). So does the MUST only apply when CoA is used, i.e., the trigger is the receipt of the CoA message not just a new name, or does the MUST apply regardless of the method used to change the tunnel name? Should "Upon receiving" be the start of a separate paragraph?
6) in 4.1, "The DS-Lite-Tunnel-Name RADIUS attribute and MUST NOT appear more than once in a message." I cannot parse this sentence (remove the 'and'?). If it is not just an extra 'and' then I don't understand the MUST requirement.
7) in 6, I disagree this attribute has no security impact beyond the basic RADIUS security consdierations. Could a MTM send multiple of access-requests with different names resulting in a denial of service attack? Especially since this attribute forces all existing tunnels to be terminated and re-established, this could generate a lot of traffic, a lot of processing overhead, and a lot of interruption of user's work..

[Ballot comment]
draft-ietf-softwire-dslite-radius-ext-04

The PROTO writeup says this draft "passes nits". However, running the ID nits tool on the draft yields an error related to a dowref. Adrian has already a discuss on it because the downref did not seem to be called out during the IETF LC. That discuss needs to be resolved before moving this draft forward.

Also, acronyms need to be expanded on their first use.

[Ballot discuss]
The document includes a downref that was not called out at IETF last
call. idnits shows it...

** Downref: Normative reference to an Informational RFC: RFC 5176

As I understand the history of 5176, it was made Informational because
it was documentation of what seveal vendors do in the field, but did
not represent consensus of the WG as a standards track protocol
extension. If that view has not changed, this document should pick one
of:

- Change the text in this document to be conditional "If an
  implementation includes...  ...it could..." and move the reference to
  informational
- Remove all text relating to 5176 and remove the reference
- Make this I-D informational
- Have the WG re-issue 5176 on the standards track. If this option is
  chosen, and the WG adopts a milestone for the work, the last call
  for this draft could be re-issued calling out the downref.

I do not believe that simply re-issuing the last call noting the downref
would be the right approach because the current status of 5176 should
not permit a downref.

[Ballot comment]
Notes from the dns-directorate review:

o In the introduction, AFTR should be expanded once, before first use

o I'm not too familiar with RADIUS folklore, so this might be obvious
  to others, but section 4 does not clearly state which format is used
  for DS-Lite-Tunnel-Name.  Section 5 later states that "The data type
  of DS-Lite-Tunnel-Name is a string", but earlier it is suggested
  that DS-Lite-Tunnel-Name be fed with the data obtained through DHCP
  in OPTION_AFTR_NAME, which is clearly in DNS wire format.  If this
  option uses text (presentation) format instead, it would need to say
  whether it's all ASCII (A-Label) or not (where it is unlikely
  anybody intended to use U-Labels).  The picture at the top of page
  9 suggests the DS-Lite-Tunnel-Name has a fixed length (of 6 octets,
  for that matter), so a more open ended graph as used in the RADIUS
  RFCs might be advised.

IANA understands that, upon approval of this document, there is a single
action required to be completed.

In the Radius Attribute Types registry in the Radius Types registry
located at:

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

a single value is to be added to the registry as follows:

Value: TBD
Description: DS-Lite-Tunnel-Name
Reference: [ RFC-to-be ]

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

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RADIUS Extensions for Dual-Stack Lite) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'RADIUS Extensions for Dual-Stack Lite'
  as a 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 2011-07-15. 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


Dual-Stack Lite is a solution to offer both IPv4 and IPv6
connectivity to customers which are addressed only with an IPv6
prefix.  DS-Lite requires to pre-configure the AFTR tunnel
information on the B4 element.  In many networks, the customer
profile information may be stored in AAA servers while client
configurations are mainly provided through DHC protocol.  This
document specifies one new RADIUS attribute to carry Dual-Stack Lite
Address Family Transition Router (AFTR) name; the RADIUS attribute is
defined based on the equivalent DHCPv6 option already specified in
draft-ietf-softwire-ds-lite-tunnel-option.  This RADIUS attribute is
meant to be used between the RADIUS Server and the NAS, it is not
intended to be used directly between the B4 element and the RADIUS
Server.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-radius-ext/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-radius-ext/


No IPR declarations have been submitted directly on this I-D.

>(1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?
Yong Cui is the Shepherd. I have reviewed the documents and
believes they ready for publication.

>(1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?
We saw evidence of some reviews on the mailing list. The documents
has been presented in softwires and was reviewed by radext too.
Comments from radext were integrated.

>(1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?
No concerns.

>(1.d) Does the Document Shepherd have any specific concerns or
> issues 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. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.
This is strictly a protocol specification.
We know of no IPR disclosures related to this document.

>(1.e) 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?
We had WG last call and there's no further comments.

>(1.f) 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
> entered into the ID Tracker.)
No.

>(1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See theInternet-Drafts
>Checklist
> andhttp://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?
Passes nits, no need for MIB Doctor reviews.

>(1.h) Has the document split its references into normative and
> informative? 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
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].
Clean.

>(1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?
There is a request to allocate a new Radius attribute type from the
IANA registry "Radius Attribute Types".


>(1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?
There is no formal language in the document.

>(1.k) 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
> Relevant content can frequently be found in the abstract
> and/or introduction of the document. If not, this may be
> an indication that there are deficiencies in the abstract
> or introduction.
RADIUS attribute
This document specifies a RADIUS attribute which contains
DS-Lite-Tunnel-Name to be used between DHCPv6 server and AAA server.
The document also describe the process combined with DHCPv6 and
optionally with PPP sessions.

> 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. There is some
disagreement over small details, but overall WG consensus is strong to
publish this document.

> 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?
We haven't seen any implementations yet, but there is a vendor
working on this.