[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed Resolution to Issue 180: Misuse of Data Types
The name "VLAN Flag" is miss leading. There is certainly a VLAN
present. The question is whether the VLAN is tagged or not. I
understand the confusion with Radius tags - though people who understand
VLANs and would be using this attribute probably wouldn't have a
problem.
If you must change the field name - which I'm not really in support of -
I suggest calling it "VLAN Tag Flag" and going with the 1 and 0
symantics of TRUE and FALSE.
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber
> (gdweber)
> Sent: Friday, March 17, 2006 9:09 AM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org
> Subject: 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/>
>
--
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/>