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

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

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