Issue 25: Issues with IEEE 802 Extensions Draft

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>]

Alan wrote a very long time ago...
 

> -----Original Message-----
> *	Subject: Re: New version of IEEE 802 Attributes Draft Available 
> *	From: "Alan DeKok" <aland@ox.org <mailto:aland%40ox.org> > 
> *	Date: Sun, 07 Nov 2004 20:03:11 -0500 
> http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee
> 802-02.txt
> > 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
draft. 

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

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

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
Vendor-Id field.:


MS

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