[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DISCUSS and COMMENT: draft-ietf-radext-design

Bernard Aboba wrote:

Thanks for your comments.
Design Guidelines has a normative dependency on the Extended Attributes document, which currently uses a 16-bit vendor type field. Given that Extended Attributes will require that RADIUS servers support a 16-bit vendor-type field for IETF-defined extended attributes, it isn't much of a stretch to recommend that RADIUS servers support a 16-bit type field for vendor and SDO-specific attributes as well, since Extended Attributes is based on the VSA format.
The question is whether that recommendation belongs in this document, which is a BCP, or whether it should go into the Extended Attributes document (Proposed Standard) instead, and just be referred to in Design Guidelines. Consolidating protocol changes into the Extended Attribute document might be cleaner, particularly since it is Extended Attributes that will provide much of the motivation for vendors to add 16-bit vendor type support. 

Seems reasonable.
With respect to "replacement" of the 8-bit vendor-type field with a 16-bit vendor type recommendation, my take on the text in 2.3 is that while it recommends RADIUS server support for 16-bit vendor type fields, it doesn't make a blanket recommendation that vendors adopt a 16-bit vendor type field in all situations, but rather points out situations in which use of a 16-bit vendor type field would be appropriate: 
   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.  In such a situation, a 16-bit Vendor type field
   would be more appropriate:
Yeah. We talked about this on the call. I think it is reasonable to go to the 16 bit space, but I was only looking for guidance for, say, an SDO that has been using 8 bits before and now has to or wants to go 16 bits. Obviously this can be done, but requires care in how the allocations are done and what dictionaries say. 

Jari



<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>



> From: jari.arkko@piuha.net
> To: iesg@ietf.org
> CC: radext-chairs@tools.ietf.org; draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; aland@freeradius.org 
> Date: Thu, 7 May 2009 07:08:20 -0700
> Subject: DISCUSS and COMMENT: draft-ietf-radext-design
>
> Discuss:
> Great doc! I will vote Yes on it, but I wanted to discuss two issues
> first, one is a Discuss-level problem and the other one a Comment that
> I'd like you to consider.
>
> The first issue is that Section 2.3 suggests 16-bit vendor space
> attribute number fields to replace the existing 8-bit recommendation.
>
> There are a couple of problems with this. First, if you really mean
> to change the recommendation, then Updates: RFC 2865 header in the
> beginning of the document would have been appropriate.
>
> Secondly, while I agree with the advice of going for 16 bits, the
> document is silent on some of the issues involved in such a change,
> such as:
>
> - Does RADIUS dictionary software support the VSA format for 16 bits, 8
> bits, or both?
>
> - How do you cleanly print or report VSAs when you do not know if the
> field size is 8 or 16 bits? I realize that this situation already
> exists since the format was never required to be followed, but
> your new recommendation makes a potential problem much more likely
> to appear. Previously, you could print something like Vendor = ACME,
> Code = 17, Contents = ABCDEF0011... Now you couldn't do that.
>
> - Can a vendor who moved from 8 bits to 16 bits deal with this?
>
> Comment:
> I do agree that for functionality FOO, both the functionality itself
> and the MIB, RADIUS, etc. work should take place in the same standards
> body. However, Section 3.1 could have said a couple of additional things
> as well:
>
> The issues of attribute space and choice of forum are distinct; there
> is no reason why IETF couldn't use its own vendor code, for instance.
>
> The section also does not mention one of the potential drawbacks of
> SDO-driven development model: it is easy to come up with a number of
> different solutions to the same generic problem, as opposed to finding
> a common solution.
>



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