Proposed Resolution to Issue 25: Issues with IEEE 802 Extensions Draft

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

  Once the proposed text included below is added to the draft, and my
one-sentence comment added[1], I agree that the issues is resolved.

   Alan DeKok.
[1] See the last line of this message.

"Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com> wrote:
> > > 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.:

  And 8 bits reserved bits, which SHOULD be zero.


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