[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed Resolution to Issue 180: Misuse of Data Types
Bernard Aboba <> supposedly scribbled:
> 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.
Sounds reasonable to me.
>
> In looking at the mailing list discussion, I did not detect consensus
> for making other changes.
Although I don't think that the discussion is altogether complete, I would agree with your assessment of its progress thus far.
>
> ----------------------------------------------------------------------------------------------------
> 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.
Hope this helps,
~gwz
Why is it that most of the world's problems can't be solved by simply
listening to John Coltrane? -- Henry Gabriel
--
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/>