Re: Questions on modified Extended Attribute format?

[Alan DeKok <aland@nitros9.org>]

Glen Zorn wrote:
> The users are being rejected because the provider of their client has
> made up his own rules about what a valid response is;

  Umm... the provider of their client is compatible with 2865, not with
the new specification allowing 2865 to be tunneled in extended
attributes.  i.e. they haven't upgraded.

  Is this permitted?  Or should we just say "too bad", and move ahead?

> Tell me the difference in effect.  As for encapsulating all the
> attributes in VSAs, that is easily handled by disqualifying the
> mandatory attributes (such as User-Name, EAP-Message, etc.) from
> inclusion.

  Then those issues need to be addressed in the extended attributes
draft.  That should triple it's size, and add another few years to the
time frame. :(

> I'm going to give you the benefit of the doubt & assume that you have
> actually read the draft & merely misspoke: the "continuation flag" is
> one bit, not one byte; the rest of that octet is the Tag field.

  I read the draft... I just don't see a need to explain what every bit
means when I'm trying to count bytes.

> Really?  The "new attribute header" that you conveniently gloss over
> above contains a 1 octet total length for the attribute, giving the same
> length limit as old-style RADIUS; of course, you could always either a)
> just concatenate "Diameter AVPs" of the same AVP type together (but then
> you can only have one AVP of a given type in a message) or b) add an
> "awkward" continuation BIT to the Flags field of the AVP...

  See Barney's comments.

> Again, I'm kind of amazed: I thought that you had implemented the WiMax
> VSAs.

  Not offically as of yet.  See the web page: no mention of WiMax.

  The Diameter stuff was easy: pack diameter AVP's (using existing
code), encapsulate in RADIUS (~50 lines of new code), etc.  The hardest
part was internal book-keeping && data structure updates.

>>   This proposal offers LESS than the "Diameter AVP in RADIUS" does,
>> at the cost of MORE work. 
> 
> See above.

  I've looked into it... the Diameter AVP stuff was easier.

> I agree completely: it is becoming rather painfully obvious (from the
> landing of red herrings (make that whales ;-), the frothing at the
> mouth, grasping at straws & confusing of implementations with standards)
> that this idea is entirely too close to useful to be approved by this
> committee.

  I thought it was that the goal-posts were changing.  Just as everyone
was resigned to accepting the format in the extended attributes draft...
it changed.

  How about this.  I'll stop arguing with the extensions to the extended
draft if you stop proposing them.  I'm willing to achieve consensus on
the basic format of the extended attributes draft:

    1 byte type
    1 byte length
    1 byte Cttttttt
    data...

  You'll note that my recent objections have NOT been to that format,
but only to the proposed extensions.

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