[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 25: Issues with IEEE 802 Extensions Draft
Alan wrote a very long time ago...
> -----Original Message-----
> * Subject: Re: New version of IEEE 802 Attributes Draft Available
> * From: "Alan DeKok" <email@example.com <mailto:aland%40ox.org> >
> * Date: Sun, 07 Nov 2004 20:03:11 -0500
> > 2.1. Egress-VLANID
> The text following this doesn't define the attribute
> format, or where the VLANID goes. ASCII art would be appreciated.
Propose following text:
"The Integer field is four octets in length. The format of the Integer
field consists of two parts, the first consuming high-order octet and
the second consuming the remaining three lower-order octets. The
high-order octet field indicates if the VLANID is allowed for tagged or
untagged packets. The second part is the 12-bit 802.1Q VLAN VID value
that has been padded out to consume the remaining three lower-order
octets. A sample encoding follows:
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
| Tag Option | Pad (12-bit) | VLANID (12-bit) |
Values for the Tag Option part include:
1 = Tagged
2 = Untagged
Padding bits SHOULD be 0 (zero).
VLANID is the 12-bit 802.1Q-2003 VID value. "
> 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.
All usage of extended attributes have been completely removed from
> 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.
All non-traditional datatypes have been removed and replaced with a
traditional RFC2865 datatypes.
> >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.
Suggestion taken. Propose following format:
"The first octet of this string indicates whether the frames on the VLAN
are tagged 0x01 or Untagged 0x02. The remaining octets represent the
VLAN Name as defined in 802.1Q-2003 clause 126.96.36.199.3 (a). UTF-8
encoded 10646 characters are recommended, but a robust implementation
SHOULD support the field as undistinguished octets."
> > 2.4. User-Priority-Table
> > Data-Type
> > UInt64
> Q: Is this the first proposed 64-bit integer data type in RADIUS?
Would have been, but as mentioned above, all usage of non-traditional
RADIUS datatypes have been removed. Therefore, 64-bit integer no longer
> >2.12. Origin-Realm
> Add missing text: This attribute is defined as an Extended
> RADIUS attribute.
This attribute has been removed from draft.
> > 3.1. Accounting-EAP-Auth-Method
> > 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.
Propose following clarifying text:
"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
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.