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

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

This looks acceptable to me. 

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

Thanks and Regards,

Dan
 

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> 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
> 
> 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
> 
> Alan DeKok wrote:
> > 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 
> radiusext-request@ops.ietf.org with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >
> >   
> 
> 

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