[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to Issue 180: Misuse of Data Types
The text of Issue 180 (and some of the subsequent discussion) is enclosed
below.
The proposed resolution is to change "VLAN Tag" to "VLAN Flag" everywhere in
the document.
In looking at the mailing list discussion, I did not detect consensus for
making other changes.
----------------------------------------------------------------------------------------------------
Issue 180: Misuse of Data Types
Submitter name: Dave Nelson
Submitter email address: dnelson@enterasys.com
Date first submitted: March 14, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html
Document: VLAN/Priority -00
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 2.1. Egress-VLANID
Rationale/Explanation of issue:
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.
[Glen Zorn]
With all due respect, I think that you are the one doing the overloading:
RFC 2568 says
integer 32 bit unsigned value, most significant octet first.
That's it. No range, no interpretation, nothing else.
[Emile Van Bergen]
I see nothing that indicates this data type is anything other than an
integer, typically expressed in a C language declaration as "unsigned
long".
You're completely correct. And in the case of the VLAN attribute, it
*does* contain an unsigned integer value, one that's calculated as follows:
value = vlanflag * 16777216 + vlanid
The reverse goes as follows:
vlanflag = value / 16777216
vlanid = value % 16777216
(where
* denotes unsigned integer multiplication,
+ denotes unsigned integer addition,
/ denotes unsigned integer division and
% denotes taking the reminder of an unsigned integer division,
all to be carried out on unsigned integers in the range 0 .. 2**32-1)
I'm not believing that people on this list would have to be explained
that shifting and masking bits are *not* magic operations that you can
only perform if you program in assembly (or its portable flavour, C),
but that those are normal mathematical operations on normal integers:
multiply and take remainder (by powers of 2).
You can do that, I think, even in Java, SAP/r3, XSLT, SQL and whatever.
This whole issue has nothing whatsoever to do with C structures.
--
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/>