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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Nelson, David <> supposedly scribbled:

> 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.  

For this to be wrong, there must be a non-infinite representation of any integer.  However, no such representation exists; the proof is left as a (trivial) exercise for the reader.

> 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.  :-)  

Indeed, there is as much as you want; the questions are, how useful is it to go down that road & (if it is at all useful), how far do we want to go?
      
> 
> 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.  

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.

> 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. 

I think that the best compromise is to strictly interpret RFC 2568.
       
> 
> 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

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/>