Re: New version of IEEE 802 Attributes Draft Available

["Alan DeKok" <aland@ox.org>]

http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt
> 2.1.  Egress-VLANID
>
>    Description
> 
>      The Egress-VLANID attribute represents an allowed IEEE 802 Egress
>      VLANID for this port.  The Egress-VLANID contains two parts: the
>      first part is the VLANID, the second part indicates if this VLANID
>      is allowed for tagged or untagged packets.

  The text following this doesn't define the attribute format, or
where the VLANID goes.  ASCII art would be appreciated.

  Section 1.2 talks about possibly using the "extended attribute"
format, and says that the following lengths are calculated using the
short form.  If so, for consistency, ASCII art of the attributes
showing the short form would be good, even if there isn't consensus
that it's the proper format to use.

  Also, the data types are "Integer32" and "UInt32".  Are these RADIUS
types, or new types?  It should be clarified as to where these types
come from.

>2.3.  VLAN-Name
>
>   Description
...
>      The VLAN-Name attribute contains two parts; the first part is the
>      VLAN name, the second part indicates if frames on the VLAN for
>      this port are to be represented in tagged or untagged format.

  I suggest arranging the attribute so that the "tagged/untagged"
information is at the same offset in the attribute as the
Egress-VLANID attribute.  Putting the value after variable-length
"String" data makes it harder to parse.  Putting the value in a
different place than in the Egress-VLANID attribute creates more
"special-case" considerations in the code.

> 2.4.  User-Priority-Table
...
> Data-Type
>
>      UInt64

  Q: Is this the first proposed 64-bit integer data type in RADIUS?

>2.12.  Origin-Realm
>
>   Description
>
>      The Origin-Realm attribute contains the realm of the originator of
>      a message, as described in [RFC3588], Section 6.4.

  Add missing text: This attribute is defined as an Extended RADIUS attribute.

> 3.1.  Accounting-EAP-Auth-Method
...
>Value
>
>      The Value field is eight octets.  In case of expanded types
>      defined in [RFC3748] Section 5.7, the least significant 32 bits
>      contain the Vendor-Type field, and the next 24 bits contain the
>      Vendor-Id field.

  Leaving 8 bits of... what?

  Again, ASCII art, even using the proposed format from Appendix A
would help clarify the attribute.

  Alan DeKok.


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