[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed Resolution to Issue 180: Misuse of Data Types
Now the VLAN-01 strawman says:
The VLAN Flag field is one octet in length,
and indicates whether the frames on the VLAN
are tagged (0x31) or untagged (0x32).
But it doesn't say *how* the flag field indicates
tagged vs. untagged. With the attribute name being
VLAN Flag, I would think that attribute's values
would be 1 or 0. Do I indicate 'tagged' by setting
the value of VLAN Flag to 1 or to 0x31?
Greg
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Thursday, March 16, 2006 1:15 PM
> To: radiusext@ops.ietf.org
> Subject: 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/>
>
--
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/>