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

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

Here is the normative language in Section 2.3:

   In order to be compatible with the above recommendations for
   attribute definitions, it is RECOMMENDED that RADIUS servers support
   attributes using a 16-bit Vendor type field.

IMHO, this doesn't suggest replacing 8-bit with 16-bit vendor type fields,
only that RADIUS servers should support 16-bit as well. 

Earlier text discusses the situations in which 16-bit vendor type fields are needed:

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


-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net] 
Sent: Thursday, May 07, 2009 7:08 AM
To: iesg@ietf.org
Cc: radext-chairs@tools.ietf.org; draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; aland@freeradius.org
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/>


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