Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Sep 2009 12:06:20 +0200

Bernard Aboba wrote:
> As a result of the change, what will Section 2.2 look like?

  Updated text after the first paragraph below:

   Note that the Vendor type field in the recommended VSA format is only
   a single octet, like the RADIUS type field.  While this limitation
   results in an efficient encoding, there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.

   These desires have led vendors to define the following non-standard
   VSA formats:

   * Vendor types of 16 bits, followed by an 8 bit length and
     then attribute-specific data.

   * Vendor types of 32 bits, followed by no length field, and
     then attribute-specific data.

   * Vendor types of the RFC format, but where some VSAs are
     defined as "grouped" or TLV attributes.  These attributes
     are then used to carry sub-attributes.

   * "Bare" ASCII strings that immediately follow the Vendor-Id,
      without using a Vendor type or Vendor length.

   All of these formats are NOT RECOMMENDED.  All VSA formats that do
   not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
   RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
   Vendor-Specific contents that are not in Type-Length-Value format.

   Although [RFC2865] does not mandate it, implementations commonly
   assume that the Vendor Id can be used as a key to determine the on-
   the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
   formats for VSAs that are associated with a particular Vendor Id.  A
   vendor wishing to use multiple VSA formats, SHOULD request one Vendor
   Id for each VSA format that they will use.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Sep 2009 13:27:54 +0300

This resolves my Discuss.

But do you want to include a strong recommendation to not use these 
formats, if the plan is to shortly thereafter publish an update of the 
VSA base format to use 16 bits? Perhaps slightly weaker language would 
be better here. E.g., "These formats are currently NOT RECOMMENDED, 
though work is ongoing to possible update the current VSA format."

Jari

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Sep 2009 14:08:07 +0200

This looks acceptable to me. 

Alan, do you plan to respin the I-D? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, September 17, 2009 1:28 PM
> To: Alan DeKok
> Cc: Bernard Aboba; Romascanu, Dan (Dan); Weber, Gregory D 
> (Greg); David B. Nelson; 'radext mailing list'
> Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
> 
> But do you want to include a strong recommendation to not use 
> these formats, if the plan is to shortly thereafter publish 
> an update of the VSA base format to use 16 bits? Perhaps 
> slightly weaker language would be better here. E.g., "These 
> formats are currently NOT RECOMMENDED, though work is ongoing 
> to possible update the current VSA format."
> 
> Jari
> 
> Alan DeKok wrote:
> > Bernard Aboba wrote:
> >

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Sep 2009 17:07:35 +0200

> Alan, do you plan to respin the I-D? 

  Yes.  I can issue one tomorrow.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Sep 2009 08:51:10 -0700

>    Vendor-Specific contents that are not in Type-Length-Value format.

How about this? 

All VSA schemes that do not follow the [RFC2865] recommendations
are NOT RECOMMENDED since these formats will typically not be
implementable without RADIUS server code changes.  This includes all 
the above formats, as well as Vendor types of more than 8 bits, vendor 
lengths of less than 8 bits, vendor lengths of more than 8 bits and 
Vendor-Specific contents that are not in Type-Length-Value format.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Sep 2009 08:54:08 -0700

How about this?

"Note that the Vendor type field in the recommended VSA format is only
a single octet, like the RADIUS type field.  While this limitation
results in an efficient encoding, there are situations in which a
vendor or SDO will eventually wish to define more than 255
attributes.  Also, an SDO can be comprised of multiple subgroups,
each of whom can desire autonomy over the definition of attributes
within their group.  The most interoperable way to address these
issues is for the vendor or SDO to request allocation of multiple
Vendor identifiers. 

However, instead of doing this, vendors have defined the following
non-standard VSA formats:"