New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

["Nelson, David" <dnelson@enterasys.com>]

Submitter name: Dave Nelson
Submitter email address: dnelson@enterasys.com
Date first submitted: March 14, 2006
Reference:
Document: VLAN/Priority -00
Comment type: 'T'echnical
Priority: '1' Should fix

Section: 2.1.  Egress-VLANID
Rationale/Explanation of issue:

Misuse of data types.  I had previously raised this issue, and the resolution was we could use a RADIUS data type of Integer, because only the VLANID (12-bit) portion would be used.  Thus, this object could be thought of as a range-limited integer.  Since I see that we still have the VLAN Tag fields, that resolution falls apart. I claim that this data object is not an Integer.

Someone offered the suggestion that Integers are not simply the mathematical definition, i.e. the positive and negative whole numbers and zero, that we all learned in high school.  With all due respect, I think that's patently wrong.  It is true that one can write programs that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data structures using mask, bit-field, shift and rotate operations.  I still claim that those data structures are *not* integers simply because they can be packed within the computer memory storage that is also used by integers.  Hopefully, there is more to data modeling than the storage length in bits.  :-)

We are currently having a debate on the RADEXT WG list about the issue of derived data types, and no consensus has yet been reached.  However, until such a consensus is reached, it seems most appropriate to follow the existing practice of defining derived data types as Strings, with the bit-fields described in the text.  I think that over-loading base RADIUS data types with new meanings is inappropriate.  Given the relative timing of WGLC on this draft and the emerging consensus on RADIUS Attribute Design Guidelines, I think this is the best compromise.

Requested change:

OLD:

Integer

      The Integer field is four octets in length.  The format is
      described below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VLAN  Tag    |        Pad            |       VLANID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The VLAN Tag field is one octet in length, and indicates whether
      the frames on the VLAN are tagged (0x31) or untagged (0x32).  The
      Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
      12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.


NEW:

String

      The String field is four octets in length.  The format is
      described below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VLAN  Tag    |        Pad            |       VLANID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The VLAN Tag field is one octet in length, and indicates whether
      the frames on the VLAN are tagged (0x31) or untagged (0x32).  The
      Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is
      12-bits in length and contains the [IEEE-802.1Q] VLAN VID value.


Section: 2.3.  Egress-VLAN-Name
Rationale/Explanation of issue:

I'm rather uncomfortable with the usage of the VLAN Tag field, as it seems to be at variance with the emerging WG consensus on complex or structured data types.  Once we standardize this usage, there will be one more precedent in a RADIUS RFC to support ad-hoc data typing.  If that's what RADEXT ultimately recommends, then this will be fine.  If the recommendation is to use a more formal method of aggregating structured data, this will be one more anomaly.

VLAN Tag

      The VLAN tag field is one octet in length, and indicates whether
      the frames on the VLAN are tagged (0x31) or untagged (0x32).

Requested change:

I have no idea what (if any change) to request.  Chalk this comment up as my personal lament over the process that RADEXT has followed -- delaying consensus on attributes design to the point where we are standardizing new attributes using complex data types prior to having defined the design guidelines for complex data types. 


Section 2.4 User-Priority-Table
Rationale/Explanation of issue:

With all due deference to the well understood "array - string duality" we find in programming languages such as C, I think that expressing a attribute whose value is an array in the form of a RADIUS String type is unfortunate, for the reasons expressed above.

Requested change:

(See above.)

The only way that I see to actually resolve my data typing / data modeling concerns is to delay sending any RADEXT work item that uses derived data types to the IESG until after we have sent the RADIUS Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, and that approach is not compatible with our milestones.

Regards,
 
Dave
 
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330  
E-mail: dnelson@enterasys.com
 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>