RADIUS Attributes for Virtual LAN and Priority Support
draft-ietf-radext-vlan-06

IANA Last Call Comments:

Upon approval of this document the IANA will register the following RADIUS Attribute Types
in http://www.iana.org/assignments/radius-types

TBD - Egress-VLANID
TBD - Ingress-Filters
TBD - Egress-VLAN-Name
TBD - User-Priority-Table

We understand the above to be the only IANA Actions for this document.

[Ballot discuss]
I am raising an issue that is largely about the same text as Dan already
commented on. But the main issue is not inconsistency in this specification
but rather the need to fulfill requirements from the WG's charter and
the desire to keep the RADIUS and Diameter protocols interoperable through
gateways.

Fortunately, I think we can correct this issue relatively easily.

The document said this:

> 4.  Diameter Considerations
>
>  Diameter needs to define identical attributes with the same Type
>  values.  The attributes should be available as part of the NASREQ
>  application [RFC4005], as well as the Diameter EAP application
>  [RFC4072].

But RADEXT charter says:

> All RADIUS work MUST be compatible with equivalent facilities in
> Diameter. Where possible, new attributes should be defined so that
> the same attribute can be used in both RADIUS and Diameter without
> translation.

In this case I believe there is no technical reason to require
different attributes. I would suggest the following contents
for Section 4:

  When used in Diameter, the attributes defined in this
  specification can be used as Diameter AVPs from the
  Code space 1-255, i.e., RADIUS attribute compatibility
  space. No additional Diameter Code values are therefore
  allocated. The data types of the attributes are as
  follows:

    Egress-VLANID                    OctetString
    Ingress-Filters                  Enumerated
    Egress-VLAN-Name                  UTF8String
    User-Priority-Table              OctetString

  The attributes in this specification have no special
  translation requirements for Diameter to RADIUS or
  RADIUS to Diameter gateways, i.e., the attributes
  are copied as is, except for changes relating to
  headers, alignment, and padding. See also
  [RFC 3588] Section 4.1 and [RFC 4005] Section 9.

  What this specification says about the applicability
  of the attributes for RADIUS Access-Request applies
  in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request
  [RFC 4072]. What is said about Access-Challenge applies
  in Diameter to AA-Answer [RFC 4005] or Diameter-EAP-Answer
  [RFC 4072] with Result-Code AVP set to
  DIAMETER_MULTI_ROUND_AUTH.

  What is said about Access-Accept applies in Diameter
  to AA-Answer or Diameter-EAP-Answer that indicates
  success. Similarly, what is said about Access-Reject
  applies in Diameter to AA-Answer or Diameter-EAP-Answer
  that indicates failure.

  What is said about COA-Request applies in Diameter
  to Re-Auth-Request [RFC 4005].

  What is said about Accounting-Request applies to
  Diameter Accounting-Request [RFC 4005] as well.

[Ballot comment]
In the Abstract:

  These attributes are usable within either RADIUS or
  Diameter.


while the Diameter Consideration section says:

  Diameter needs to define identical attributes with the same Type
  values.

The statements seem to be contradictory. Same attributes usable within both protocols, which actually would mean that this document applie for both, or identical attributes with same Type values but yet to be defined within Diameter? I suggest that the text be fixed or incremented to clarify this.

PROTO writeup:

Title:  RADIUS Attributes for Virtual LAN and Priority Support
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-04.txt

Status: Proposed Standard

Response to template:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes. The ID has had 3 working group last calls.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No concerns.  The document has been reviewed by the RADEXT working group,
members of IEEE 802.1, and Dan Romascanu.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) 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?
There is solid consensus behind this document.  8 people responded to
WG last call.  The issues raised, available for inspection at
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -04
version of the document.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes. An output of the run on this revision of the ID by the online nits
checker:

idnits 1.92

tmp/draft-ietf-radext-vlan-04.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
- The page length should not exceed 58 lines per page, but there was 13
  longer pages, the longest (page 2) being 60 lines
- It seems as if not all pages are separated by form feeds - found 0 form
  feeds but 14 pages

  Miscellaneous warnings:
    None.

  Experimental warnings:
  - Unused Reference: [RFC3748] is defined on line 495, but not referenced
        '[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.'

    No nits found.

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

The document does split references into normative and informative ones.
There are no normative references to IDs.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This document describes Virtual LAN (VLAN) and re-prioritization
attributes that may prove useful for provisioning of access to IEEE
802 local area networks with the Remote Authentication Dialin User
Service (RADIUS).  The attributes defined in this document provide
support within RADIUS analogous to the management variables supported
in IEEE-802.1Q and MIB objects defined in RFC 4363.

  - Working Group Summary

There have been 3 WGLCs on the document, the initial one was
part of the IEEE 802 attributes document, and the last two as
a standalone document.  Discussion on the document related
to the use of the Tag Indication field, details of the
User-Priority-Table attribute and per-user vs. per-port
provisioning.